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

- Security fix: [bsc#1220262, CVE-2023-50782]  * Implicit rejection in PKCS#1 v1.5
  * Add openssl-CVE-2023-50782.patch

- Security fix: [bsc#1227138, CVE-2024-5535]
  * SSL_select_next_proto buffer overread
  * Add openssl-CVE-2024-5535.patch

Package python was updated:

- Add CVE-2024-11168-validation-IPv6-addrs.patch  fixing bsc#1233307 (CVE-2024-11168,
  gh#python/cpython#103848): Improper validation of IPv6 and
  IPvFuture addresses.
- Add ipaddress module from https://github.com/phihag/ipaddress
- Remove -IVendor/ from python-config boo#1231795

- Stop using %%defattr, it seems to be breaking proper executable
  attributes on /usr/bin/ scripts (bsc#1227378).

Package google-guest-configs was updated:

- Update to version 20241121.00 (bsc#1233625, bsc#1233626)  * Temporarily revert google_set_multiqueue changes for release (#92)
- from version 20241115.00
  * Remove IDPF devices from renaming rules (#91)
- from version 20241112.00
  * Revert &amp;quot;Revert 3 commits:&amp;quot; (#89)
- from version 20241108.00
  * Revert 3 commits: (#87)
- from version 20241107.00
  * gce-nic-naming: Exit 1 so that udev ignores the rule on error (#86)
- from version 20241106.00
  * Remove Apt IPv4 only config for Debian and Ubuntu (#85)
- from version 20241031.00
  * Add GCE intent based NIC naming tools (#84)
- from version 20241025.00
  * Update google_set_multiqueue to skip set_irq
    if NIC is not a gvnic device (#83)
- Add new binary gce-nic-naming to %{_bindir} in %files section

- Update to version 20241021.00 (bsc#1231775, bsc#1231776)
  * Add GCE-specific config for systemd-resolved (#82)
- from version 20241015.00
  * Update google_set_multiqueue to enable on A3Ultra family (#79)
- from version 20241013.00
  * Update OWNERS (#81)
- from version 20241010.00
  * Depend on jq in enterprise linux (#80)
- from version 20241008.00
  * Always use IP from primary NIC in the
    networkd-dispatcher routable hook (#78)

- Update to version 20240925.00
  * Call google_set_hostname on openSUSE and when the agent
    is configured to manage hostname and FQDN, let it (#75)
- from version 20240924.00
  * Include systemd-networkd hook in Ubuntu packaging (#77)
- from version 20240905.00
  * Update packaging as of Ubuntu devel packaging (#65)
- from version 20240830.00
  * Fix the name for A3 Edge VMs (#76)

- Update to version 20240725.00
  * Fix: hostnamectl command (#74)

- Update to version 20240607.00
  * Update is_a3_platform to include A3-edge shape (#73)

- Update to version 20240514.00
  * Add systemd-networkd hostname hook (#71)
- from version 20240501.00
  * Add hostname hook for NetworkManager without
    dhclient compat script (#70)

Package kernel-default was updated:

- x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client (bsc#1234072 CVE-2024-53114).- commit ace41bd

- Update
  patches.suse/initramfs-avoid-filename-buffer-overrun.patch
  (CVE-2024-53142 bsc#1232436).
- commit c12c103

- Bluetooth: af_bluetooth: Fix deadlock (CVE-2024-26886
  bsc#1223044).
- Bluetooth: Avoid potential use-after-free in hci_error_reset
  (CVE-2024-26801 bsc#1222413).
- commit 0002c48

- dm cache: fix potential out-of-bounds access on the first resume
  (bsc#1233467, CVE-2024-50278).
- dm cache: optimize dirty bit checking with find_next_bit when
  resizing (bsc#1233467, CVE-2024-50278).
- commit 0b89286

- Update References: field,
  patches.suse/dm-cache-fix-out-of-bounds-access-to-the-dirty-bitset-when-resizing.patch
  (bsc#1233467, bsc#1233468, CVE-2024-50278, CVE-2024-50279).
- commit 3ad9690

- dm cache: fix flushing uninitialized delayed_work on cache_ctr
  error (bsc#1233467, CVE-2024-50278).
- dm cache: correct the number of origin blocks to match the
  target length (bsc#1233467, CVE-2024-50278).
- commit 4bc71b8

- can: bcm: Clear bo-&amp;gt;bcm_proc_read after remove_proc_entry()
  (CVE-2024-46771 bsc#1230766).
- commit 491eb77

- ocfs2: uncache inode which has failed entering the group (bsc#1234087).
- commit 8d46222

- sch/netem: fix use after free in netem_dequeue (CVE-2024-46800
  bsc#1230827).
- can: bcm: Remove proc entry when dev is unregistered
  (CVE-2024-46771 bsc#1230766).
- commit 4db26bc

- media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED
  in uvc_parse_format (CVE-2024-53104 bsc#1234025).
- commit 5e374e6

- USB: serial: io_edgeport: fix use after free in debug printk (CVE-2024-50267 bsc#1233456)
- commit 5cba6cd

- usb: typec: altmode should keep reference to parent (CVE-2024-50150 bsc#1233051)
- commit 42ad9b3

- net: hns3: fix kernel crash when uninstalling driver (CVE-2024-50296 bsc#1233485)
- commit 184c4c0

- drm/vc4: Warn if some v3d code is run on BCM2711 (bsc#1233108)
  Only take struct vc4file.dev for bsc#1233108. Leave out the commit's
  tests and warnings.
- commit 7eeddbe

- net: relax socket state check at accept time (git-fixes).
- commit 4a31544

- tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
  (CVE-2024-36905 bsc#1225742).
- commit 9ad4cc7

- drm/vc4: Stop the active perfmon before being destroyed (bsc#1233108 CVE-2024-50187)
- commit f0f44d8

- wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit (CVE-2024-49938 bsc#1232552)
- commit 4092e67

- netfilter: nf_tables: prevent nf_skb_duplicated corruption (CVE-2024-49952 bsc#1232157)
- commit 0b60580

- security/keys: fix slab-out-of-bounds in key_task_permission
  (CVE-2024-50301 bsc#1233490).
- commit 6e6d2aa

- media: cx24116: prevent overflows on SNR calculus
  (CVE-2024-50290 bsc#1233479).
- commit 12a43db

- dm cache: fix out-of-bounds access to the dirty bitset when
  resizing (CVE-2024-50279 bsc#1233468).
- commit a5eeed1

- nvme-pci: fix race condition between reset and
  nvme_dev_disable() (bsc#1232888 CVE-2024-50135).
- commit d800691

- scsi: lpfc: Ensure DA_ID handling completion before deleting
  an NPIV instance (bsc#1233130 CVE-2024-50183).
- commit 2341eee

- tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink()
  (CVE-2024-50154 bsc#1233070).
  Patch has been manually modified to apply.
- commit e2aba08

- nfs: Fix KMSAN warning in decode_getfattr_attrs()
  (CVE-2024-53066 bsc#1233560).
- commit b4e2ec3

- btrfs: fix a NULL pointer dereference when failed to start a
  new trasacntion (CVE-2024-49868 bsc#1232272).
- commit 28e08c8

- Reinstate some of &amp;quot;swiotlb: rework &amp;quot;fix info leak with
  DMA_FROM_DEVICE&amp;quot;&amp;quot; (CVE-2022-48853 bsc#1228015).
- commit ddba53c

- HID: core: zero-initialize the report buffer (CVE-2024-50302
  bsc#1233491).
- commit 6bc7fd8

- vsock/virtio: Initialization of the dangling pointer occurring
  in vsk-&amp;gt;trans (CVE-2024-50264 bsc#1233453).
- commit edf6fa0

- net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged
  SKB data (CVE-2024-53058 bsc#1233552).
- commit ebde361

- Bluetooth: SCO: Fix UAF on sco_sock_timeout (CVE-2024-50125
  bsc#1232928).
- Bluetooth: call sock_hold earlier in sco_conn_del
  (CVE-2024-50125 bsc#1232928).
- commit 4838e6d

- Update
  patches.suse/posix-clock-posix-clock-Fix-unbalanced-locking-in-pc.patch
  (CVE-2024-50195 bsc#1233103 CVE-2024-50210 bsc#1233097).
- commit 4b1cf97

- mm: revert &amp;quot;mm: shmem: fix data-race in shmem_getattr()&amp;quot;
  (CVE-2024-50228, bsc#1233204, git fixes (mm/shmem)).
- commit 84efe19

- posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime() (CVE-2024-50195 bsc#1233103)
- commit dede472

- media: av7110: fix a spectre vulnerability (CVE-2024-50289
  bsc#1233478).
- commit 43a6f6e

- efi/memattr: Ignore table if the size is clearly bogus
  (CVE-2024-49858 bsc#1232251 bsc#1231465).
- commit 3272541

- i40e: fix race condition by adding filter's intermediate sync
  state (CVE-2024-53088 bsc#1233580).
- i40e: fix i40e_count_filters() to count only active/new filters
  (CVE-2024-53088 bsc#1233580).
- commit c0c4369

- ocfs2: remove entry once instead of null-ptr-dereference in
  ocfs2_xa_remove() (bsc#1233454 CVE-2024-50265).
- commit 3e0d522

- net: hns3: fix a deadlock problem when config TC during
  resetting (CVE-2024-44995 bsc#1230231).
- commit 398b1db

- media: dvbdev: prevent the risk of out of memory access
  (CVE-2024-53063 bsc#1233557).
- commit 62f1f9b

- tpm: Lock TPM chip in tpm_pm_suspend() first (bsc#1082555
  git-fixes CVE-2024-53085 bsc#1233577).
- commit 70d272c

- media: s5p-jpeg: prevent buffer overflows (CVE-2024-53061
  bsc#1233555).
- commit 506c426

- Update
  patches.suse/tipc-fix-a-possible-memleak-in-tipc_buf_append.patch
  (bsc#1221977 CVE-2021-47162 bsc#1225764 CVE-2024-36954
  CVE-2024-36886 bsc#1225730).
- commit 6b7c8a5

- net: netem: use a list in addition to rbtree
  (git-fixes CVE-2024-45016 bsc#1230429).
- commit 2b0774f

- swiotlb: fix info leak with DMA_FROM_DEVICE (CVE-2022-48853
  bsc#1228015).
- commit 56fe90d

- crypto: ecdh - explicitly zeroize private_key (CVE-2024-42098
  bsc#1228779).
- commit ef82dbf

- crypto: aead,cipher - zeroize key buffer after use
  (CVE-2024-42229 bsc#1228708).
- commit 1b83698

- btrfs: reinitialize delayed ref list after deleting it from
  the list (bsc#1233462 CVE-2024-50273).
- commit 0901f0b

- Refresh
  patches.suse/net-prevent-mss-overflow-in-skb_segment.patch.
  Fix the following warning:
  net/core/skbuff.c: In function 'skb_segment':
  include/linux/kernel.h:795:16: warning: comparison of distinct pointer types lacks a cast [enabled by default]
  include/linux/kernel.h:798:2: note: in expansion of macro '__min'
  net/core/skbuff.c:3302:18: note: in expansion of macro 'min'
  This is how the warning got silenced in upstream stable kernel
  v4.19.321.
- commit 68ad1ea

- Refresh
  patches.suse/scsi-lpfc-Validate-hdwq-pointers-before-dereferencin.patch.
  Adjust the backport to match the old size of struct members. This
  fixes the following warning:
  ../drivers/scsi/lpfc/lpfc_sli.c: In function 'lpfc_sli_flush_io_rings':
  ../drivers/scsi/lpfc/lpfc_sli.c:4436:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'int' [-Wformat=]
  ../drivers/scsi/lpfc/lpfc_sli.c:4436:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type 'uint32_t' [-Wformat=]
- commit dff4c6e

- kernel-binary: Enable livepatch package only when livepatch is enabled
  Otherwise the filelist may be empty failing the build (bsc#1218644).
- commit f730eec

- Update config files (bsc#1218644).
  LIVEPATCH_IPA_CLONES=n =&amp;gt; LIVEPATCH=n
- commit b1b7b65

- posix-clock: Fix missing timespec64 check in pc_clock_settime() (CVE-2024-50195 bsc#1233103)
- commit 41e678c

- net: systemport: fix potential memory leak in bcm_sysport_xmit() (CVE-2024-50171 bsc#1233057)
- commit a8cf9c8

- Bluetooth: bnep: fix wild-memory-access in proto_unregister (CVE-2024-50148 bsc#1233063)
- commit cb3dc55

- tty: n_gsm: Fix use-after-free in gsm_cleanup_mux (CVE-2024-50073 bsc#1232520)
- commit 68babec

- Update
  patches.suse/arm64-probes-Fix-uprobes-for-big-endian-kernels.patch
  (git-fixes CVE-2024-50194 bsc#1233111).
- Update
  patches.suse/arm64-probes-Remove-broken-LDR-literal-uprobe-support.patch
  (git-fixes CVE-2024-50099 bsc#1232887).
- Update
  patches.suse/ceph-remove-the-incorrect-Fw-reference-check-when-dir.patch
  (bsc#1231184 CVE-2024-50179 bsc#1233123).
- commit c9a203b

- ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow
  (bsc#1233191 CVE-2024-50218).
- commit cc4dbc4

- Update tags in
  patches.suse/ext4-fix-slab-use-after-free-in-ext4_split_extent_at.patch
  (bsc#1232201 CVE-2024-49884 bsc#1232198).
- commit dcc8f26

- Fix compiler warnings introduced in
  patches.suse/udf-Avoid-excessive-partition-lengths.patch.
- commit fc54634

- mm: shmem: fix data-race in shmem_getattr() (CVE-2024-50228,
  bsc#1233204, git fixes (mm/shmem)).
- commit e71d93b

- driver core: bus: Fix double free in driver API bus_register()
  (bsc#1232329 CVE-2024-50055).
- commit 0448963

- KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory
  (CVE-2024-50115 bsc#1232919).
- commit 0050d80

- drm/amd: Guard against bad data for ATIF ACPI method (bsc#1232897 CVE-2024-50117)
- commit 97c9929

- wifi: mac80211: do not pass a stopped vif to the driver in
  .get_txpower (CVE-2024-50237 bsc#1233216).
- commit 6d8f0b7

- wifi: ath10k: Fix memory leak in management tx (CVE-2024-50236
  bsc#1233212).
- commit 0b6cbda

- wifi: iwlegacy: Clear stale interrupts before resuming device
  (CVE-2024-50234 bsc#1233211).
- commit 01cb9ce

- drm/amd/display: Check null pointers before used (bsc#1232371 CVE-2024-49921)
- commit e8deeae

- net/ncsi: Disable the ncsi work before freeing the associated
  structure (CVE-2024-49945 bsc#1232165).
- commit a88491e

- Update tags
  patches.suse/mm-Avoid-overflows-in-dirty-throttling-logic.patch
  (bsc#1222364 CVE-2024-42131 bsc#1228650).
- commit 3f14d21

- RDMA/mad: Improve handling of timed out WRs of mad agent (bsc#1232873 CVE-2024-50095)
- commit 2d90f41

- IB/mad: Issue complete whenever decrements agent refcount (bsc#1232873 CVE-2024-50095)
- commit 27da1c4

- be2net: fix potential memory leak in be_xmit() (CVE-2024-50167
  bsc#1233049).
- commit 4f25cff

- cpufreq: brcmstb-avs-cpufreq: ISO C90 forbids mixed declarations
  (CVE-2024-27051 bsc#1223769).
- commit 6437a99

- driver core: Fix error return code in really_probe()
  (bsc#1232224 CVE-2024-49925).
- commit 7264309

- parport: Proper fix for array out-of-bounds access (CVE-2024-50074 bsc#1232507)
- commit ee8e094

- cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's
  return value (CVE-2024-27051 bsc#1223769).
- commit e56562b

- vfs: fix race between evice_inodes() and find_inode()&amp;amp;iput()
  (bsc#1231930 CVE-2024-47679).
- commit ebf12b1

- ext4: avoid OOB when system.data xattr changes underneath the
  filesystem (bsc#1231920 CVE-2024-47701).
- commit 06b6d21

- ext4: explicitly exit when ext4_find_inline_entry returns an
  error (bsc#1231920 CVE-2024-47701).
- commit 76db0bc

- ext4: return error on ext4_find_inline_entry (bsc#1231920
  CVE-2024-47701).
- commit 3ce9700

- ext4: ext4_search_dir should return a proper error (bsc#1231920
  CVE-2024-47701).
- commit 35d9543

- wifi: cfg80211: check A-MSDU format more carefully (stable-fixes
  CVE-2024-35937 bsc#1224526).
- blacklist.conf: remove the entry that we're just adding
- commit efe6631

- driver core: kABI workaround for dev_groups in device_driver
  (bsc#1232224 CVE-2024-49925).
- commit 993ec78

- initramfs: avoid filename buffer overrun (bsc#1232436).
- commit 7ae8606

- driver core: add dev_groups to all drivers (bsc#1232224
  CVE-2024-49925).
- commit d16dce7

- fbdev: efifb: Register sysfs groups through driver core
  (bsc#1232224 CVE-2024-49925).
- commit bff3087

- NFC: nci: Bounds check struct nfc_target arrays (bsc#1232304 CVE-2022-48967)
- commit 5a26fef

- net: hisilicon: Fix potential use-after-free in hix5hd2_rx() (bsc#1231979 CVE-2022-48960)
- commit e5b93cf

- kabi/severities: ignore amdgpu symbols
  amdkfd symbols are exported but they are supposed to be used only
  by amdgpu, so they are local symbols that can be ignored.
- commit 381c434

- ipv6: avoid use-after-free in ip6_fragment() (CVE-2022-48956
  bsc#1231893).
- commit fea62f0

- scsi: lpfc: Validate hdwq pointers before dereferencing in
  reset/errata paths (bsc#1232218 CVE-2024-49891).
- commit b5db475

- SLE12-SP5 turned LTSS (Extended Security) - maintainership goes to L3
- commit 6e14d1d

- Bluetooth: RFCOMM: FIX possible deadlock in
  rfcomm_sk_state_change (CVE-2024-50044 bsc#1231904).
- commit e681821

- tipc: guard against string buffer overrun (CVE-2024-49995
  bsc#1232432).
- commit ba288b6

- net/xen-netback: prevent UAF in xenvif_flush_hash()
  (CVE-2024-49936 bsc#1232424).
- commit 2fa13cf

- drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer
  (CVE-2024-49991 bsc#1232282).
- commit ce009ae

- Remove duplicate CVE references
  Update patches.suse/nvme-fix-a-possible-use-after-free-in-controller-res.patch
  Update patches.suse/nvme-rdma-fix-possible-use-after-free-in-transport-e.patch
  Update patches.suse/nvme-tcp-fix-possible-use-after-free-in-transport-er.patch
- commit 2663e32

- mm: split critical region in remap_file_pages() and invoke
  LSMs in between (CVE-2024-47745 bsc#1232135 git-fix).
- commit 661d796

- nfs: fix memory leak in error path of nfs4_do_reclaim
  (git-fixes).
- nfsd: fix delegation_blocked() to block correctly for at least
  30 seconds (git-fixes).
- commit 05c4d99

- Update
  patches.suse/IB-core-Implement-a-limit-on-UMAD-receive-List.patch
  (bsc#1228743 CVE-2024-42145 bsc#1223384).
- Update
  patches.suse/RDMA-cxgb4-Added-NULL-check-for-lookup_atid.patch
  (git-fixes CVE-2024-47749 bsc#1232180).
- Update
  patches.suse/RDMA-iwcm-Fix-WARNING-at_kernel-workqueue.c-check_fl.patch
  (git-fixes CVE-2024-47696 bsc#1231864).
- Update
  patches.suse/aoe-fix-the-potential-use-after-free-problem-in-more.patch
  (bsc#1218562 CVE-2023-6270 CVE-2024-49982 bsc#1232097).
- Update patches.suse/media-edia-dvbdev-fix-a-use-after-free.patch
  (CVE-2024-27043 bsc#1223824 bsc#1218562).
- Update
  patches.suse/ocfs2-fix-null-ptr-deref-when-journal-load-failed.patch
  (git-fixes CVE-2024-49957 bsc#1232152).
- Update
  patches.suse/ocfs2-fix-possible-null-ptr-deref-in-ocfs2_set_buffer_uptodate.patch
  (git-fixes CVE-2024-49877 bsc#1232339).
- Update
  patches.suse/ocfs2-remove-unreasonable-unlock-in-ocfs2_read_blocks.patch
  (git-fixes CVE-2024-49965 bsc#1232142).
- commit d1259c0

- Update
  patches.suse/nfc-nci-fix-possible-NULL-pointer-dereference-in-sen.patch
  (bsc#1219125 CVE-2023-46343 CVE-2023-52919 bsc#1231988).
- Update
  patches.suse/tcp-do-not-accept-ACK-of-bytes-we-never-sent.patch
  (CVE-2023-52881 bsc#1225611 bsc#1223384).
- commit 9477732

- Update
  patches.suse/char-tpm-Protect-tpm_pm_suspend-with-locks.patch
  (bsc#1082555 CVE-2022-48997 bsc#1232035).
- Update
  patches.suse/igb-Initialize-mailbox-message-for-VF-reset.patch
  (git-fixes CVE-2022-48949 bsc#1231897).
- Update
  patches.suse/net-mana-Fix-race-on-per-CQ-variable-napi-work_done.patch
  (bsc#1229154 CVE-2022-48985 bsc#1231958).
- Update
  patches.suse/nvme-fix-a-possible-use-after-free-in-controller-res.patch
  (bsc#1227941 (CVE-2022-48790) CVE-2022-48790).
- Update
  patches.suse/nvme-rdma-fix-possible-use-after-free-in-transport-e.patch
  (bsc#1227952 (CVE-2022-48788) CVE-2022-48788).
- Update
  patches.suse/nvme-tcp-fix-possible-use-after-free-in-transport-er.patch
  (bsc#1228000 (CVE-2022-48789) CVE-2022-48789).
- Update
  patches.suse/udf-Fix-preallocation-discarding-at-indirect-extent-.patch
  (bsc#1213034 CVE-2022-48946 bsc#1231888).
- Update
  patches.suse/xen-netfront-Fix-NULL-sring-after-live-migration.patch
  (git-fixes CVE-2022-48969 bsc#1232026).
- commit c8e7e6a

- Update patches.suse/phy-mdio-fix-memory-leak.patch (git-fixes
  bsc#1225336 CVE-2021-47416 bsc#1225189).
- commit 9036983

- smb: client: fix UAF in async decryption (bsc#1232418,
  CVE-2024-50047).
- commit f679375

- drm/amd/display: Fix index out of bounds in degamma hardware format translation (CVE-2024-49894 bsc#1232354)
- commit b558147

- drm/msm/adreno: Assign msm_gpu-&amp;gt;pdev earlier to avoid nullptrs (CVE-2024-49901 bsc#1232305)
- commit 9c2561f

- ext4: fix i_data_sem unlock order in ext4_ind_migrate() (CVE-2024-50006 bsc#1232442)
- commit 8639f10

- ALSA: asihpi: Fix potential OOB array access (CVE-2024-50007 bsc#1232394)
- commit 013518a

- jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error (CVE-2024-49959 bsc#1232149)
- commit 284567a

- ACPI: sysfs: validate return type of _STR method (bsc#1231861
  CVE-2024-49860).
- commit aede924

- mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths
  (CVE-2022-48991 bsc#1232070).
- commit bc2150c

- mm/khugepaged: fix GUP-fast interaction by sending IPI
  (CVE-2022-48991 bsc#1232070 prerequisity).
- commit 1df90ba

- khugepaged: retract_page_tables() remember to test exit
  (CVE-2022-48991 bsc#1232070 prerequisity).
- commit f4a1619

- ext4: update orig_path in ext4_find_extent() (CVE-2024-49881 bsc#1232201)
- commit b5dc210

- ext4: fix slab-use-after-free in ext4_split_extent_at() (bsc#1232201)
- commit 693aa17

- btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info()
  in walk_down_proc() (CVE-2024-46841 bsc#1231094).
- commit 6d306f6

- ext4: aovid use-after-free in ext4_ext_insert_extent() (CVE-2024-49883 bsc#1232199)
- commit ec16b20

- wifi: iwlwifi: mvm: avoid NULL pointer dereference (CVE-2024-49929 bsc#1232253)
- commit 84425bf

- net: fix a memleak when uncloning an skb dst and its metadata
  (CVE-2022-48809 bsc#1227947).
- commit 2bf5e2a

- tpm: Clean up TPM space after command failure (CVE-2024-49851
  bsc#1232134).
- commit 7bbb5a1

- serial: protect uart_port_dtr_rts() in uart_shutdown() too
  (CVE-2024-50058 bsc#1232285).
- commit 41b7884

- ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() (CVE-2024-49962 bsc#1232314)
- commit 4df8d00

- drm/amd/display: Check stream before comparing them (CVE-2024-49896 bsc#1232221)
- commit b1fe975

- drm/amd/pm: ensure the fw_info is not null before using it (CVE-2024-49890 bsc#1232217)
- commit c3be196

- ASoC: ops: Correct bounds check for second channel on SX controls (CVE-2022-48951 bsc#1231929)
- commit bf654bc

- firmware_loader: Block path traversal (CVE-2024-47742 bsc#1232126)
- commit 7af5448

- ASoC: soc-pcm: Add NULL check in BE reparenting (CVE-2022-48992 bsc#1232071)
- commit 70e6117

- media: pci: cx23885: check cx23885_vdev_init() return (CVE-2023-52918 bsc#1232047)
- commit 713adf4

- ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx() (CVE-2022-48951 bsc#1231929)
- commit 26bb290

- btrfs: clean up our handling of refs == 0 in snapshot delete (CVE-2024-46840 bsc#1231105)
- commit 61febb6

- drm/amd/display: Check null pointers before multiple uses (bsc#1232313 CVE-2024-49920)
- commit 2448039

- iommu/vt-d: Fix PCI device refcount leak in  has_external_pci()
  (bsc#1232123 CVE-2022-49000).
- commit 02b654b

- net: mvneta: Fix an out of bounds check (CVE-2022-48966
  bsc#1232191).
- commit 0317c39

- iommu/vt-d: Fix PCI device refcount leak in
  dmar_dev_scope_init() (bsc#1232133 CVE-2022-49002).
- commit 5c0b5c2

- net: hisilicon: Fix potential use-after-free in hisi_femac_rx()
  (CVE-2022-48962 bsc#1232286).
- commit fc49b9f

- ppp: fix ppp_async_encode() illegal access (CVE-2024-50035
  bsc#1232392).
- net: avoid potential underflow in qdisc_pkt_len_init() with UFO
  (CVE-2024-49949 bsc#1232160).
- net: mvneta: Prevent out of bounds read in mvneta_config_rss()
  (CVE-2022-48966 bsc#1232191).
- net/9p: Fix a potential socket leak in p9_socket_open
  (CVE-2022-49020 bsc#1232175).
- commit 2c23eba

- hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()
  (bsc#1232006 CVE-2022-49011).
- hwmon: (coretemp) Check for null before removing sysfs attrs
  (bsc#1232172 CVE-2022-49010).
- hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc()
  fails (bsc#1231995 CVE-2022-49029).
- commit 71880ba

- Update
  patches.suse/0001-x86-kaslr-Expose-and-use-the-end-of-the-physical-mem.patch
  (bsc#1230405, bsc#1232236).
- commit a8a279f

- mm: call the security_mmap_file() LSM hook in remap_file_pages()
  (CVE-2024-47745 bsc#1232135).
- commit ed0f269

- Bluetooth: L2CAP: Fix uaf in l2cap_connect (CVE-2024-49950
  bsc#1232159).
- commit 30ab1b9

- arm64: probes: Fix uprobes for big-endian kernels (git-fixes)
- commit 3e6f9a6

- arm64: probes: Fix simulate_ldr*_literal() (git-fixes)
- commit a1137d7

- arm64: probes: Remove broken LDR (literal) uprobe support (git-fixes)
- commit e35a346

- arm64: esr: Define ESR_ELx_EC_* constants as UL (git-fixes)
- commit 03723c2

- ext4: fix double brelse() the buffer of the extents path
  (bsc#1232200 CVE-2024-49882).
- ext4: no need to continue when the number of entries is 1
  (bsc#1232140 CVE-2024-49967).
- commit fc369f8

- ethernet: aeroflex: fix potential skb leak in greth_init_rings()
  (CVE-2022-48958 bsc#1231889).
- e100: Fix possible use after free in e100_xmit_prepare
  (CVE-2022-49026 bsc#1231997).
- iavf: Fix error handling in iavf_init_module() (CVE-2022-49027
  bsc#1232007).
- ixgbevf: Fix resource leak in ixgbevf_init_module()
  (CVE-2022-49028 bsc#1231996).
- net: phy: fix null-ptr-deref while probe() failed
  (CVE-2022-49021 bsc#1231939).
- commit ed7ba02

- net: usb: usbnet: fix name regression (get-fixes).
- commit 505fee4

- drm/amd/display: Check gpio_id before used as array index (CVE-2024-46818 bsc#1231203).
- commit 38ee0dd

- drbd: Fix atomicity violation in drbd_uuid_set_bm() (git-fixes).
- drbd: Add NULL check for net_conf to prevent dereference in
  state validation (git-fixes).
- commit 8ea7f3b

- gpio: amd8111: Fix PCI device reference count leak (CVE-2022-48973 bsc#1232039)
- commit cbd0482

- Bluetooth: Fix not cleanup led when bt_init fails (CVE-2022-48971 bsc#1232037)
- commit ce6c97c

- cifs: Fix buffer overflow when parsing NFS reparse points
  (bsc#1232089, CVE-2024-49996).
- commit 009c8ed

- netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() (CVE-2024-47685 bsc#1231998)
- commit 6b03439

- net: Fix an unsafe loop on the list (CVE-2024-50024 bsc#1231954)
- commit b3d8cae

- ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() (CVE-2024-47707 bsc#1231935)
- commit 4b59ef3

- mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add() (CVE-2022-48972 bsc#1232025)
- commit 0168947

- HID: core: fix shift-out-of-bounds in hid_report_raw_event (CVE-2022-48978 bsc#1232038)
- commit 7a79be0

- netfilter: br_netfilter: fix panic with metadata_dst skb (CVE-2024-50045 bsc#1231903)
- commit 2c7a2ef

- block, bfq: fix possible UAF for bfqq-&amp;gt;bic with merge chain (CVE-2024-47706 bsc#1231942)
- commit c8fc3bd

- tcp: check skb is non-NULL in tcp_rto_delta_us() (CVE-2024-47684 bsc#1231987)
- commit 3560609

- net: hsr: Fix potential use-after-free (CVE-2022-49015 bsc#1231938)
- commit 6ebc760

- ocfs2: cancel dqi_sync_work before freeing oinfo (bsc#1232141
  CVE-2024-49966).
- commit b3c314a

- RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled (bsc#1232111 CVE-2024-47735)
- commit 78adc47

- ocfs2: reserve space for inline xattr before attaching reflink
  tree (bsc#1232151 CVE-2024-49958).
- commit 75ba1c4

- wifi: mac80211: use two-phase skb reclamation in
  ieee80211_do_stop() (CVE-2024-47713 bsc#1232016).
- commit 6ae0d21

- nfsd: call cache_put if xdr_reserve_space returns NULL
  (bsc#1232056 CVE-2024-47737).
- commit 629ef18

- Update
  patches.suse/memcg-Fix-possible-use-after-free-in-memcg_write_event_control.patch
  (bsc#1206344, CVE-2022-48988, bsc#1232069).
- commit 3727547

- slip: make slhc_remember() more robust against malicious packets
  (CVE-2024-50033 bsc#1231914).
- net: tun: Fix use-after-free in tun_detach() (CVE-2022-49014
  bsc#1231890).
- commit c68baf4

- md/raid5: fix deadlock that raid5d() wait for itself to clear
  MD_SB_CHANGE_PENDING (bsc#1227437, CVE-2024-39476).
- Delete the following patch, it is replaced by the above one,
  patches.suse/Revert-md-raid5-Wait-for-MD_SB_CHANGE_PENDING-in-rai.patch.
- commit e9834f3

- net/ipv6: prevent use after free in ip6_route_mpath_notify
  (CVE-2024-26852 bsc#1223057 bsc#1230784).
- Update
  patches.suse/net-ipv6-avoid-possible-UAF-in-ip6_route_mpath_notif.patch
  (CVE-2024-26852 bsc#1223057 bsc#1230784).
- commit 7d060a6

- drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds
  write  error (bsc#1231858 CVE-2024-47697).
- drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds
  write  error (bsc#1231859 CVE-2024-47698).
- commit d62c304

- ethtool: fail closed if we can't get max channel used in
  indirection tables (CVE-2024-46834 bsc#1231096).
- commit bddfacf

- gpio: prevent potential speculation leaks in
  gpio_device_get_desc() (stable-fixes CVE-2024-44931
  bsc#1229837).
- commit 664410d

- gpio: pca953x: fix pca953x_irq_bus_sync_unlock race
  (stable-fixes CVE-2024-42253 bsc#1229005).
- commit 966ef70

- mm: avoid leaving partial pfn mappings around in error case
  (CVE-2024-47674 bsc#1231673).
- commit b85f7d9

- udf: Avoid excessive partition lengths (bsc#1230773
  CVE-2024-46777).
- fsnotify: clear PARENT_WATCHED flags lazily (bsc#1231439
  CVE-2024-47660).
- commit 1cf833b

- netem: fix return value if duplicate enqueue fails
  (CVE-2024-45016 bsc#1230429).
- net: netem: fix use after free and double free with packet
  corruption (git-fixes CVE-2024-45016 bsc#1230429).
- net: netem: correct the parent's backlog when corrupted packet
  was dropped (git-fixes CVE-2024-45016 bsc#1230429).
- net: netem: fix error path for corrupted GSO frames (git-fixes
  CVE-2024-45016 bsc#1230429).
- net: netem: fix backlog accounting for corrupted GSO frames
  (git-fixes CVE-2024-45016 bsc#1230429).
- commit 8535e0c

- perf/x86/intel: Limit the period on Haswell (bsc#1231072,
  CVE-2024-46848).
- commit ddcb55d

- Update
  patches.suse/ocfs2-add-bounds-checking-to-ocfs2_xattr_find_entry.patch
  (bsc#1228410 CVE-2024-41016 CVE-2024-47670 bsc#1231537).
- commit 3c9794f

- wifi: iwlwifi: mvm: pause TCM when the firmware is stopped
  (CVE-2024-47673 bsc#1231539).
- commit ec71cef

- wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead
  (CVE-2024-47672 bsc#1231540).
- commit bf00ca5

- sched/smt: Fix unbalance sched_smt_present dec/inc
  (CVE-2024-44958 bsc#1230179).
- commit d76ce7a

- add bug reference for a mana change (bsc#1229769).
- commit 365e607

- nfc: fix segfault in nfc_genl_dump_devices_done (CVE-2021-47612 bsc#1226585)
- commit 04d816c

- aoe: fix the potential use-after-free problem in more places
  (bsc#1218562 CVE-2023-6270).
- commit 9a97d1d

- xhci: Fix null pointer dereference when host dies
  (CVE-2023-52898 bsc#1229568).
- commit 8083a37

- bpf: Fix pointer-leak due to insufficient speculative store
  bypass mitigation (bsc#1231375).
- commit 8169915

- wifi: mwifiex: Do not return unused priv in
  mwifiex_get_priv_by_id() (bsc#1230802 CVE-2024-46755).
- commit 3faac0d

- Delete some more obsolete scripts
- commit c036565

- drm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links (CVE-2024-46816 bsc#1231197).
- commit fce3225

- drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number (bsc#1230725 CVE-2024-46724)
- commit a6d26f5

- drm/amd/display: Check link_index before accessing dc-&amp;gt;links (CVE-2024-46813 bsc#1231191).
- commit 6cd35ce

- rpm/release-projects: Add SLFO projects (bsc#1231293).
- commit 9f2c584

- Update kabi files from rpm-4.12.14-122.228
  Some nvme symbols are listed as exported from vmlinux while the driver
  is modular. This is because the symvers files were not updated after
  making the driver modular.
- commit 00d2c7f

- ELF: fix kernel.randomize_va_space double read (CVE-2024-46826 bsc#1231115)
  Dropped const and split declaration and assignment to avoid warning of
  mixing declarations and statements.
- commit 8b66569

- drm/amd/display: added NULL check at start of dc_validate_stream (CVE-2024-46802 bsc#1231111)
- commit a598fc3

- Revert &amp;quot;Merge branch 'users/dwagner/SLE12-SP5/for-next' into SLE12-SP5&amp;quot;
  This reverts commit aa4c39a920ecb484add5aa1733bbaa0fb81c7d46, reversing
  changes made to 4527634da2625f9c0c83176368afe9fe8acb3ffc.
  - --
  Following breaks kABI:
  commit 72d636029eff5515a118fd98f44689c4421a836e
  Author: Daniel Wagner &amp;lt;dwagner@suse.de&amp;gt;
  Date:   Mon Sep 30 15:48:52 2024 +0200
  kabi: ignore all nvme kabi breakages
  Streamline sle12sp5 with the other code stream where we ignore
  all symbol changes inside the nvme subsystem.
  Delete:
  - patches.kabi/kabi-Fix-nvme-fabrics_q.patch
  - patches.kabi/kabi-Fix-nvmet-error-log-definitions.patch
  - patches.kabi/kabi-nvme-fix-fast_io_fail_tmo.patch
  - --
  As designed the path match does not match symbols exported from vmlinux
  (built-in), those have to be listed explicitly.
  Listing the offending symbols should make this change work. It's
  possible that more of the nvme support is modular on later kernels or
  the kABI brekage is not as widespread compared to 4.12.
  - ---
- commit 5f0ddca

- net: dpaa: Pad packets to ETH_ZLEN (CVE-2024-46854 bsc#1231084).
- ice: Add netif_device_attach/detach into PF reset flow
  (CVE-2024-46770 bsc#1230763).
- net: core: Specify skb_pad()/skb_put_padto() SKB freeing
  (CVE-2024-46854 bsc#1231084).
- commit 8314902

- usbnet: fix cyclical race on disconnect with work queue
  (git-fixes).
- Refresh
  patches.kabi/move-new-members-of-struct-usbnet-to-end.patch.
- Refresh
  patches.suse/0002-Add-a-void-suse_kabi_padding-placeholder-to-some-USB.patch.
- commit d5af998

- powerpc/imc-pmu: Revert nest_init_lock to being a mutex
  (bsc#1065729).
- commit 9d9f624

- powerpc/xmon: Fix disassembly CPU feature checks (bsc#1065729).
- powerpc/pseries: fix possible memory leak in ibmebus_bus_init()
  (bsc#1065729).
- powerpc/imc-pmu: Fix use of mutex in IRQs disabled section
  (bsc#1054914 fate#322448 git-fixes).
- powerpc/iommu: Annotate nested lock for lockdep (bsc#1065729).
- commit 1b7c467

- Fix bsc#1054914 reference.
- commit 4b9db88

- nvme: avoid double free special payload (bsc#1228635
  CVE-2024-41073).
- commit 50941e4

- ceph: remove the incorrect Fw reference check when dirtying
  pages (bsc#1231184).
- commit 4527634

- rpm/check-for-config-changes: add HAVE_RUST and RUSTC_SUPPORTS_ to IGNORED_CONFIGS_RE
  They depend on SHADOW_CALL_STACK.
- commit 65fa52b

- nvmet: always initialize cqe.result (bsc#1228615
  CVE-2024-41079).
- commit 0c4e344

- kabi/severities: Ignore ppc instruction emulation (bsc#1230826 ltc#205848)
  These are lowlevel functions not used outside of exception handling and
  kernel debugging facilities.
- commit abc513a

- drm/amd/display: Check BIOS images before it is used (CVE-2024-46809 bsc#1231148).
- commit 006eae3

- platform/x86: panasonic-laptop: Fix SINF array out of bounds
  accesses (CVE-2024-46859 bsc#1231089).
- commit 59d5c89

- spi: nxp-fspi: fix the KASAN report out-of-bounds bug
  (CVE-2024-46853 bsc#1231083).
- commit bb10262

- media: vivid: fix compose size exceed boundary (CVE-2022-48945
  bsc#1230398).
- commit 9b78931

- kthread: Fix task state in kthread worker if being frozen
  (bsc#1231146).
- commit acf39f7

- kabi: ignore all nvme kabi breakages
  Streamline sle12sp5 with the other code stream where we ignore
  all symbol changes inside the nvme subsystem.
  Delete:
  - patches.kabi/kabi-Fix-nvme-fabrics_q.patch
  - patches.kabi/kabi-Fix-nvmet-error-log-definitions.patch
  - patches.kabi/kabi-nvme-fix-fast_io_fail_tmo.patch
- commit 72d6360

- nvme-fabrics: use reserved tag for reg read/write command
  (bsc#1228620 CVE-2024-41082).
  Refresh:
  - patches.kabi/kabi-Fix-nvme-fabrics_q.patch
- nvme-fabrics: use reserved tag for reg read/write command
  (bsc#1228620 CVE-2024-41082).
- nvme: change __nvme_submit_sync_cmd() calling conventions
  (bsc#1228620 CVE-2024-41082).
- nvme: remove unused timeout parameter (bsc#1228620
  CVE-2024-41082).
- nvme: split nvme_alloc_request() (bsc#1228620 CVE-2024-41082).
  Refresh:
  - patches.suse/lightnvm-remove-lightnvm-implemenation.patch
- nvme: centralize setting the timeout in nvme_alloc_request
  (bsc#1228620 CVE-2024-41082).
  Refresh:
  - patches.suse/lightnvm-remove-lightnvm-implemenation.patch
- commit 1db4029

- tracing: Avoid possible softlockup in tracing_iter_reset()
  (git-fixes).
- commit 6f4c555

- arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry (bsc#1231120 CVE-2024-46822)
- commit cd9816b

- arm64: acpi: Move get_cpu_for_acpi_id() to a header (bsc#1231120 CVE-2024-46822)
- commit 0c95f6d

- tracing: Fix overflow in get_free_elt() (git-fixes
  CVE-2024-43890 bsc#1229764).
- commit 2519a16

- drm/amd/pm: fix the Out-of-bounds read warning (bsc#1230709 CVE-2024-46731)
- commit 1b11b68

- af_unix: Fix data races around sk-&amp;gt;sk_shutdown (bsc#1226846).
- af_unix: annotate lockless accesses to sk-&amp;gt;sk_err (bsc#1226846).
- commit 7b2aa7b

- drm/amdgpu: fix mc_data out-of-bounds read warning (CVE-2024-46722 bsc#1230712)
- commit 7ff2284

- i2c: lpi2c: Avoid calling clk_get_rate during transfer
  (bsc#1227885 CVE-2024-40965).
- commit 115f782

- Update
  patches.suse/fuse-Initialize-beyond-EOF-page-contents-before-setti.patch
  (bsc#1229457 CVE-2024-44947 bsc#1229456).
- Update
  patches.suse/msft-hv-3046-uio_hv_generic-Fix-kernel-NULL-pointer-dereference-i.patch
  (git-fixes CVE-2024-46739 bsc#1230732).
- Update
  patches.suse/msft-hv-3048-net-mana-Fix-error-handling-in-mana_create_txq-rxq-s.patch
  (git-fixes CVE-2024-46784 bsc#1230771).
- Update
  patches.suse/nvmet-tcp-fix-kernel-crash-if-commands-allocation-fa.patch
  (git-fixes CVE-2024-46737 bsc#1230730).
- Update
  patches.suse/powerpc-rtas-Prevent-Spectre-v1-gadget-construction-.patch
  (bsc#1227487 CVE-2024-46774 bsc#1230767).
- commit ad5a546

- userfaultfd: fix checks for huge PMDs (CVE-2024-46787
  bsc#1230815).
- commit a5d0a66

- PCI: xilinx-nwl: Clean up clock on probe failure/removal
  (git-fixes).
- commit ace75db

- net: ip_tunnel: prevent perpetual headroom growth
  (CVE-2024-26804 bsc#1222629).
- commit 7a0d3d3

- net: tunnels: annotate lockless accesses to dev-&amp;gt;needed_headroom
  (CVE-2024-26804 bsc#1222629).
- Refresh
  patches.kabi/kabi-preserve-struct-header_ops-after-bsc-1176081-fi.patch.
- commit 4908ccc

- kabi: add __nf_queue_get_refs() for kabi compliance
  (bsc#1229633,CVE-2022-48911).
- commit ffffe4c

- netfilter: nf_queue: fix possible use-after-free (bsc#1229633,
  CVE-2022-48911).
- commit c9290c8

- RDMA/cxgb4: Added NULL check for lookup_atid (git-fixes)
- commit a4946ef

- RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency (git-fixes)
- commit 4ef1336

- RDMA/core: Remove unused declaration rdma_resolve_ip_route() (git-fixes)
- commit 7580f3e

- kABI fix for tipc: wait and exit until all work queues are done
  (CVE-2021-47163 bsc#1221980).
- commit 685278e

- tipc: wait and exit until all work queues are done
  (CVE-2021-47163 bsc#1221980).
- commit 60b5a40

- btrfs: handle errors from btrfs_dec_ref() properly (CVE-2024-46753 bsc#1230796)
- commit ab888f1

- net: bridge: xmit: make sure we have at least eth header len
  bytes (CVE-2024-38538 bsc#1226606).
- commit 37ef8fc

- x86/kaslr: Expose and use the end of the physical memory
  address space (bsc#1230405).
- commit 151c0a3

- Delete
  patches.suse/cifs-fix-double-free-race-when-mount-fails-in-cifs_get_root-.patch.
  This patch should have been only in kernel v5.11+, which is when
  the double free issue was introduced.
- commit 92bb491

- pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv (CVE-2024-46761 bsc#1230761)
- commit 0c20c64

- hwmon: (adc128d818) Fix underflows seen when writing limit attributes (CVE-2024-46759 bsc#1230814)
- commit 8ed41b4

- Input: uinput - reject requests with unreasonable number of slots (CVE-2024-46745 bsc#1230748)
- commit 9508651

- VMCI: Fix use-after-free when removing resource in vmci_resource_remove() (CVE-2024-46738 bsc#1230731)
- commit 98e87d9

- tcp_bpf: fix return value of tcp_bpf_sendmsg() (CVE-2024-46783 bsc#1230810)
- commit f6705ba

- Update references in patches.suse/nvmet-tcp-fix-kernel-crash-if-commands-allocation-fa.patch (CVE-2024-46737 bsc#1230730)
- commit 91952f9

- nvmet: Identify-Active Namespace ID List command should reject
  invalid nsid (git-fixes).
- nvmet-tcp: fix kernel crash if commands allocation fails
  (git-fixes).
- commit 07a5a05

- net: fix use-after-free in tw_timer_handler (CVE-2021-46936
  bsc#1220439).
- commit b2028df

- drm/msm/dpu: cleanup FB if dpu_format_populate_layout fails (CVE-2024-44982 bsc#1230204).
- commit 4f660ab

- drm/amdgpu: fix ucode out-of-bounds read warning (bsc#1230702 CVE-2024-46723)
- commit ff45869

- Update
  patches.suse/nfc-nci-Fix-uninit-value-in-nci_rx_work.patch
  (git-fixes CVE-2024-38381 bsc#1226878).
- Update
  patches.suse/vfio-pci-fix-potential-memory-leak-in-vfio_intx_enab.patch
  (git-fixes CVE-2024-38632 bsc#1226860).
  Add CVE references.
- commit bd6ac3f

- PCI: Add missing bridge lock to pci_bus_lock() (CVE-2024-46750
  bsc#1230783).
- commit 6d64b3d

- Squashfs: sanity check symbolic link size (bsc#1230747 CVE-2024-46744)
- commit 067cd70

- ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate
  (git-fixes).
- commit 36cf250

- ocfs2: remove unreasonable unlock in ocfs2_read_blocks
  (git-fixes).
- commit 13d7dfe

- ocfs2: fix null-ptr-deref when journal load failed (git-fixes).
- commit 4386caf

- powerpc/ppc-opcode: Add divde and divdeu opcodes (bsc#1230826
  ltc#205848).
- powerpc/lib/sstep: Add XER bits introduced in POWER ISA v3.0
  (bsc#1230826 ltc#205848).
- commit 4de0867

- of/irq: Prevent device address out-of-bounds read in interrupt
  map walk (CVE-2024-46743 bsc#1230756).
- commit 8403759

- driver: iio: add missing checks on iio_info's callback access
  (CVE-2024-46715 bsc#1230700).
- commit f7336e3

- pinctrl: single: fix potential NULL dereference in pcs_get_function() (CVE-2024-46685 bsc#1230515)
- commit e892b22

- usb: dwc3: core: Prevent USB core invalid event buffer address access (CVE-2024-46675 bsc#1230533)
- commit 9657973

- thunderbolt: Mark XDomain as unplugged when router is removed (CVE-2024-46702 bsc#1230589)
- commit 74749bb

- smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req() (CVE-2024-46686 bsc#1230517)
- commit 9cca3e0

- scsi: aacraid: Fix double-free on probe failure (CVE-2024-46673 bsc#1230506)
- commit b132ff0

- apparmor: fix possible NULL pointer dereference (CVE-2024-46721 bsc#1230710)
- commit 2b27b0b

- gtp: fix a potential NULL pointer dereference (CVE-2024-46677 bsc#1230549)
- commit b3221e1

- nfc: pn533: Add poll mod list filling check (CVE-2024-46676 bsc#1230535)
- commit 0ff9f28

- ethtool: check device is present when getting link settings (CVE-2024-46679 bsc#1230556).
- commit 34a40a8

- powerpc/sstep: Fix darn emulation (bsc#1230826 ltc#205848).
- powerpc/sstep: Fix incorrect return from analyze_instr()
  (bsc#1230826 ltc#205848).
- commit be8f831

- powerpc/lib/sstep: Fix 'sthcx' instruction (bsc#1230826
  ltc#205848).
- powerpc/lib/sstep: fix 'ptesync' build error (bsc#1230826
  ltc#205848).
- powerpc/sstep: Check instruction validity against ISA version
  before emulation (bsc#1230826 ltc#205848).
- powerpc/fpu: Drop cvt_fd() and cvt_df() (bsc#1230826
  ltc#205848).
- Refresh patches.suse/powerpc-Don-t-clobber-f0-vs0-during-fp-altivec-regis.patch
- powerpc/sstep: Add support for divde[.] and
  divdeu[.] instructions (bsc#1230826 ltc#205848).
- powerpc/lib: fix redundant inclusion of quad.o (bsc#1230826
  ltc#205848).
- powerpc sstep: Add support for modsd, modud instructions
  (bsc#1230826 ltc#205848).
- powerpc sstep: Add support for modsw, moduw instructions
  (bsc#1230826 ltc#205848).
- powerpc sstep: Add support for extswsli instruction (bsc#1230826
  ltc#205848).
- powerpc sstep: Add support for cnttzw, cnttzd instructions
  (bsc#1230826 ltc#205848).
- powerpc: sstep: Add support for darn instruction (bsc#1230826
  ltc#205848).
- powerpc: sstep: Add support for maddhd, maddhdu, maddld
  instructions (bsc#1230826 ltc#205848).
- Refresh patches.suse/powerpc-bpf-use-unsigned-division-instruction-for-64.patch
- powerpc/sstep: Fix kernel crash if VSX is not present
  (bsc#1230826 ltc#205848).
- powerpc/sstep: Introduce GETTYPE macro (bsc#1230826 ltc#205848).
- powerpc/lib: Fix &amp;quot;integer constant is too large&amp;quot; build failure
  (bsc#1230826 ltc#205848).
- powerpc/32: Move the inline keyword at the beginning of function
  declaration (bsc#1230826 ltc#205848).
- powerpc/kprobes: Blacklist emulate_update_regs() from kprobes
  (bsc#1230826 ltc#205848).
- powerpc/lib/sstep: Fix fixed-point shift instructions that
  set CA32 (bsc#1230826 ltc#205848).
- powerpc/lib/sstep: Fix fixed-point arithmetic instructions
  that set CA32 (bsc#1230826 ltc#205848).
- powerpc/kprobes: Update optprobes to use emulate_update_regs()
  (bsc#1230826 ltc#205848).
- powerpc: Fix handling of alignment interrupt on dcbz instruction
  (bsc#1230826 ltc#205848).
- powerpc: Fix kernel crash in emulation of vector loads and
  stores (bsc#1230826 ltc#205848).
- commit 41c7998

- md/raid5: avoid BUG_ON() while continue reshape after
  reassembling (bsc#1229790, CVE-2024-43914).
- commit 2925547

- powerpc/lib/sstep: Fix count leading zeros instructions
  (bsc#1230826 ltc#205848).
- powerpc/sstep: mullw should calculate a 64 bit signed result
  (bsc#1230826 ltc#205848).
- powerpc/sstep: Fix issues with mcrf (bsc#1230826 ltc#205848).
- powerpc/sstep: Fix issues with set_cr0() (bsc#1230826
  ltc#205848).
- powerpc/sstep: Avoid used uninitialized error (bsc#1230826
  ltc#205848).
- powerpc: Wrap register number correctly for string load/store
  instructions (bsc#1230826 ltc#205848).
- powerpc: Emulate load/store floating point as integer word
  instructions (bsc#1230826 ltc#205848).
- powerpc: Use instruction emulation infrastructure to handle
  alignment faults (bsc#1230826 ltc#205848).
- Refresh patches.suse/powerpc-Fix-check-for-copy-paste-instructions-in-ali.patch
- Update config files.
- powerpc: Separate out load/store emulation into its own function
  (bsc#1230826 ltc#205848).
- powerpc: Handle opposite-endian processes in emulation code
  (bsc#1230826 ltc#205848).
- powerpc: Set regs-&amp;gt;dar if memory access fails in emulate_step()
  (bsc#1230826 ltc#205848).
- powerpc: Emulate the dcbz instruction (bsc#1230826 ltc#205848).
- powerpc: Emulate load/store floating double pair instructions
  (bsc#1230826 ltc#205848).
- powerpc: Emulate vector element load/store instructions
  (bsc#1230826 ltc#205848).
- powerpc: Emulate FP/vector/VSX loads/stores correctly when
  regs not live (bsc#1230826 ltc#205848).
- powerpc: Make load/store emulation use larger memory accesses
  (bsc#1230826 ltc#205848).
- powerpc: Add emulation for the addpcis instruction (bsc#1230826
  ltc#205848).
- powerpc: Don't update CR0 in emulation of popcnt, prty, bpermd
  instructions (bsc#1230826 ltc#205848).
- powerpc: Fix emulation of the isel instruction (bsc#1230826
  ltc#205848).
- powerpc/64: Fix update forms of loads and stores to write
  64-bit EA (bsc#1230826 ltc#205848).
- powerpc: Handle most loads and stores in instruction emulation
  code (bsc#1230826 ltc#205848).
- powerpc: Don't check MSR FP/VMX/VSX enable bits in
  analyse_instr() (bsc#1230826 ltc#205848).
- powerpc: Change analyse_instr so it doesn't modify *regs
  (bsc#1230826 ltc#205848).
- powerpc/lib/sstep: Add isel instruction emulation (bsc#1230826
  ltc#205848).
- powerpc/lib/sstep: Add prty instruction emulation (bsc#1230826
  ltc#205848).
- powerpc/lib/sstep: Add bpermd instruction emulation (bsc#1230826
  ltc#205848).
- powerpc/lib/sstep: Add popcnt instruction emulation (bsc#1230826
  ltc#205848).
- powerpc/lib/sstep: Add cmpb instruction emulation (bsc#1230826
  ltc#205848).
- commit 10b1c67

- KABI: kcm: Serialise kcm_sendmsg() for the same socket
  (CVE-2024-44946 bsc#1230015).
- commit 7a83511

- kcm: Serialise kcm_sendmsg() for the same socket
  (CVE-2024-44946 bsc#1230015).
- commit a7c5ad6

- KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3
  (CVE-2024-46707 bsc#1230582).
- commit a6e55a2

- perf: Fix list corruption in perf_cgroup_switch() (bsc#1227953
  CVE-2022-48799).
- commit 7c98d1e

- nvme-tcp: fix possible use-after-free in transport
  error_recovery work (bsc#1228000 (CVE-2022-48789)).
- nvme: fix a possible use-after-free in controller reset  during
  load (bsc#1227941 (CVE-2022-48790)).
- commit 699f243

- x86/mtrr: Check if fixed MTRRs exist before saving them (bsc#1230174 CVE-2024-44948).
- commit c14b9b5

- nvme-rdma: fix possible use-after-free in transport
  error_recovery work (bsc#1227952 (CVE-2022-48788)).
- commit 0f2b472

- Input: MT - limit max slots (CVE-2024-45008 bsc#1230248).
- commit 18c0fe4

- Refresh
  patches.suse/media-cec-core-avoid-confusing-transmit-timed-out-me.patch.
  Moved into sorted section to avoid false positives of the checker
- commit 6e68152

- media: vivid: avoid integer overflow (git-fixes).
- commit 2e17cad

- netlink: extend policy range validation
  (prerequisite  CVE-2024-42114 bsc#1228564).
- Refresh patches.kabi/netlink-nla_policy-kabi-workaround.patch.
- commit 1f2aeb8

- media: vivid: dev-&amp;gt;bitmap_cap wasn't freed in all cases
  (git-fixes).
- commit 249a367

- media: vivid: s_fbuf: add more sanity checks (git-fixes).
- commit de48b55

- media: vivid: fix assignment of dev-&amp;gt;fbuf_out_flags (git-fixes).
- commit 0c654cd

- ipv6: prevent UAF in ip6_send_skb() (CVE-2024-44987 bsc#1230185)
- commit a6345f7

- gtp: pull network headers in gtp_dev_xmit() (CVE-2024-44999 bsc#1230233)
- commit 6133ce9

- powerpc: Remove support for PowerPC 601 (Remove unused and
  malformed assembly causing build error).
- commit a186115

- Drivers: hv: vmbus: Fix rescind handling in uio_hv_generic
  (git-fixes).
- uio_hv_generic: Fix kernel NULL pointer dereference in
  hv_uio_rescind (git-fixes).
- net: mana: Fix error handling in mana_create_txq/rxq's NAPI
  cleanup (git-fixes).
- net: mana: Fix race of mana_hwc_post_rx_wqe and new hwc response
  (git-fixes).
- commit 2c432a7

- profiling: fix shift too large makes kernel panic (git-fixes).
- commit 92e9109

- KVM: x86/mmu: make apf token non-zero to fix bug (CVE-2022-48943
  bsc#1229645).
- commit 20aabb8

- media: dvb-usb-v2: af9035: fix missing unlock (CVE-2023-52915
  bsc#1230270).
- commit 48622c6

- media: dvb-usb-v2: af9035: Fix null-ptr-deref in
  af9035_i2c_master_xfer (CVE-2023-52915 bsc#1230270).
- commit a6997db

- usbnet: modern method to get random MAC (git-fixes).
- commit 26fa49e

- net: usb: sr9700: fix uninitialized variable use in sr_mdio_read
  (git-fixes).
- commit f6a8914

- ACPI: EC: Avoid printing confusing messages in acpi_ec_setup()
  (git-fixes).
- ACPI: EC: tweak naming in preparation for GpioInt support
  (git-fixes).
- ACPI / EC: Clean up EC GPE mask flag (git-fixes).
- ACPI: EC: Fix an EC event IRQ storming issue (git-fixes).
- commit 9e80cf5

- Bluetooth: hci_core: Fix leaking sent_cmd skb (CVE-2022-48844 bsc#1228068)
- commit 33c7b67

- wifi: nl80211: disallow setting special AP channel widths (CVE-2024-43912 bsc#1229830)
- commit 3f6faef

- scsi: pm8001: Fix use-after-free for aborted TMF sas_task (CVE-2022-48791 bsc#1228002)
- commit 0f736ca

- scsi: pm80xx: Fix TMF task completion race condition (CVE-2022-48791 bsc#1228002)
- commit 47ce134

- ext4: sanity check for NULL pointer after ext4_force_shutdown
  (bsc#1229753 CVE-2024-43898).
- commit d2ce48d

- udf: Avoid using corrupted block bitmap buffer (bsc#1229362
  CVE-2024-42306).
- commit e9fe84a

- ext4: check dot and dotdot of dx_root before making dir indexed
  (bsc#1229363 CVE-2024-42305).
- commit 1e9d591

- protect the fetch of -&amp;gt;fd[fd] in do_dup2() from mispredictions
  (bsc#1229334 CVE-2024-42265).
- commit 126ef02

- ACPI: video: Add new hw_changes_brightness quirk, set it on
  PB Easynote MZ35 (git-fixes).
- ACPI: blacklist: fix clang warning for unused DMI table
  (git-fixes).
- Revert &amp;quot;ACPI / EC: Remove old CLEAR_ON_RESUME quirk&amp;quot;
  (git-fixes).
- ACPI: SPCR: Consider baud rate 0 as preconfigured state
  (git-fixes).
- ACPI: SPCR: work around clock issue on xgene UART (git-fixes).
- commit 18ef221

- ACPI: SPCR: Workaround for APM X-Gene 8250 UART 32-alignment
  errata (git-fixes).
- Refresh
  patches.suse/0001-tty-pl011-fix-initialization-order-of-QDF2400-E44.patch.
- commit 0985189

- serial: sc16is7xx: fix invalid FIFO access with special register
  set (CVE-2024-44950 bsc#1230180).
- commit b162aad

- kabi fix for proc/mounts: add cursor (bsc#1207341).
- commit 1fada3d

- proc/mounts: add cursor (bsc#1207341).
- autofs4: use wait_event_killable (bsc#1207341).
- commit 1adc77e

- ALSA: line6: Fix racy access to midibuf (CVE-2024-44954
  bsc#1230176).
- commit 899798d

- atm: idt77252: prevent use after free in dequeue_rx()
  (CVE-2024-44998 bsc#1230171).
- driver core: Fix uevent_show() vs driver detach race
  (CVE-2024-44952 bsc#1230178).
- commit c758c1a

- cpufreq: schedutil: Destroy mutex before kobject_put() frees the memory (CVE-2021-47387 bsc#1225316)
- commit ce3e04b

- s390/sclp: Prevent release of buffer in I/O (bsc#1230200
  CVE-2024-44969 git-fixes).
- commit 495f327

- wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values
  (CVE-2024-42114 bsc#1228564).
  Refresh patches.kabi/netlink-nla_policy-kabi-workaround.patch.
- commit 9abf38c

- fuse: use unsigned type for getxattr/listxattr size truncation
  (bsc#1230151).
- commit 3543834

- Bluetooth: L2CAP: Fix not validating setsockopt user input
  (bsc#1224579 CVE-2024-35965).
- commit 6d78576

- Bluetooth: L2CAP: Fix deadlock (git-fixes).
- commit 6afc15c

- Bluetooth: btintel: Fixe build regression (bsc#1224640
  CVE-2024-35933).
- commit 67f9898

- Bluetooth: btintel: Fix null ptr deref in btintel_read_version
  (bsc#1224640 CVE-2024-35933).
- commit 8955b3c

- usb: vhci-hcd: Do not drop references before new references
  are gained (CVE-2024-43883 bsc#1229707).
- commit 1ab205e

- bluetooth/l2cap: sync sock recv cb and release (bsc#1228576
  CVE-2024-41062).
- commit 7294061

- drm/i915/gem: Fix Virtual Memory mapping boundaries calculation (bsc#1229156 CVE-2024-42259)
- commit ad9c138

- net: usb: qmi_wwan: fix memory leak for not ip packets
  (CVE-2024-43861 bsc#1229500).
- commit 706ebe0

- drm/vmwgfx: Fix a deadlock in dma buf fence polling (bsc#1229497 CVE-2024-43863)
- commit 3f53b56

- xfs: fix getfsmap reporting past the last rt extent (git-fixes).
- commit a9800d1

- xfs: fix uninitialized variable access (git-fixes).
- commit 3f7682d

- xfs: Fix the owner setting issue for rmap query in xfs fsmap
  (git-fixes).
- commit f1b3405

- Update
  patches.suse/0001-usb-xhci-Check-endpoint-is-valid-before-dereferencin.patch
  (git-fixes CVE-2023-52901 bsc#1229531).
- Update
  patches.suse/CDC-NCM-avoid-overflow-in-sanity-checking.patch
  (git-fixes CVE-2022-48938 bsc#1229664).
- Update
  patches.suse/RDMA-cma-Do-not-change-route.addr.src_addr-outside-s.patch
  (bsc#1210629 CVE-2023-2176 CVE-2022-48925 bsc#1229630).
- Update patches.suse/RDMA-ib_srp-Fix-a-deadlock.patch (git-fixes
  CVE-2022-48930 bsc#1229624).
- Update
  patches.suse/cgroup-cpuset-Prevent-UAF-in-proc_cpuset_show.patch
  (bsc#1228801 CVE-2024-43853 bsc#1229292).
- Update
  patches.suse/cifs-fix-double-free-race-when-mount-fails-in-cifs_get_root-.patch
  (bsc#1190317 CVE-2022-48919 bsc#1229657).
- Update
  patches.suse/configfs-fix-a-race-in-configfs_-un-register_subsystem.patch
  (git-fixes CVE-2022-48931 bsc#1229623).
- Update patches.suse/drm-virtio-Fix-GEM-handle-creation-UAF.patch
  (git-fixes CVE-2022-48899 bsc#1229536).
- Update
  patches.suse/ibmvnic-free-reset-work-item-when-flushing.patch
  (bsc#1196516 ltc#196391 CVE-2022-48905 bsc#1229604).
- Update patches.suse/ixgbe-fix-pci-device-refcount-leak.patch
  (git-fixes CVE-2022-48896 bsc#1229540).
- Update
  patches.suse/memcg-protect-concurrent-access-to-mem_cgroup_idr.patch
  (git-fixes CVE-2024-43892 bsc#1229761).
- Update
  patches.suse/scsi-qla2xxx-Complete-command-early-within-lock.patch
  (bsc#1228850 CVE-2024-42287 bsc#1229392).
- Update
  patches.suse/scsi-qla2xxx-During-vport-delete-send-async-logout-e.patch
  (bsc#1228850 CVE-2024-42289 bsc#1229399).
- Update
  patches.suse/scsi-qla2xxx-Fix-for-possible-memory-corruption.patch
  (bsc#1228850 CVE-2024-42288 bsc#1229398).
- Update
  patches.suse/scsi-qla2xxx-validate-nvme_local_port-correctly.patch
  (bsc#1228850 CVE-2024-42286 bsc#1229395).
- commit d202e91

- ata: libata-core: Fix double free on error
  (CVE-2024-41087,bsc#1228466).
- commit bdef5f8

- drm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rules (CVE-2024-43907 bsc#1229787).
- commit 95a59bd

- drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr (CVE-2024-43905 bsc#1229784).
- commit 93f42ad

- serial: core: check uartclk for zero to avoid divide by zero
  (bsc#1229759 CVE-2024-43893).
- commit 150a54e

- media: xc2028: avoid use-after-free in load_firmware_cb()
  (CVE-2024-43900 bsc#1229756).
- commit 764489c

- Revert &amp;quot;irqdomain: Fixed unbalanced fwnode get and put (git-fixes).&amp;quot;
  (bsc#1229851)
  This reverts commit 37becc871554a4057226a862be812b4c0ff8c711 as it
  breaks irqs on 12sp5. The patch is actually wrong in 12sp5. of_node is
  refcounted here, not fwnode. So revert the patch without replacement.
- commit c53dc2f

- drm/amd/display: Add null checker before passing variables (CVE-2024-43902 bsc#1229767).
- commit 1c0c16f

- Bluetooth: MGMT: Add error handling to pair_device() (CVE-2024-43884 bsc#1229739)
- commit ecb471c

- btrfs: get rid of warning on transaction commit when using
  flushoncommit (bsc#1229658 CVE-2022-48920).
- commit 2ac5fdc

- vfio/pci: fix potential memory leak in vfio_intx_enable()
  (git-fixes).
- commit f6c36eb

- kABI: vfio: struct virqfd kABI workaround (CVE-2024-26812
  bsc#1222808).
- commit 202caf3

- exec: Fix ToCToU between perm check and set-uid/gid usage
  (CVE-2024-43882 bsc#1229503).
- commit 236a83a

- vfio: Introduce interface to flush virqfd inject workqueue
  (bsc#1222808 CVE-2024-26812).
- commit 71f96a8

- vfio/pci: Create persistent INTx handler (bsc#1222808
  CVE-2024-26812).
- commit 26ca5db

- ip6_tunnel: Fix broken GRO (bsc#1226323).
- net/mlx5: Always drain health in shutdown callback
  (CVE-2024-43866 bsc#1229495).
- commit d1b0995

- net: ipv6: ensure we call ipv6_mc_down() at most once (CVE-2022-48910 bsc#1229632)
- commit 80d1e79

- gsmi: fix null-deref in gsmi_get_variable (CVE-2023-52893 bsc#1229535)
- commit 0d2fd7b

- Fix reference in patches.suse/netfilter-tproxy-bail-out-if-IP-has-been-disabled-on.patch (CVE-2024-36270 bsc#1226798)
- commit 705c30b

- s390/pkey: Wipe copies of protected- and secure-keys
  (CVE-2024-42155 bsc#1228733).
- commit 1712d5c

- nfc: pn533: initialize struct pn533_out_arg properly
  (CVE-2022-48875 bsc#1229516).
- commit 3dc4ecc

- nfc: pn533: Wait for out_urb's completion in
  pn533_usb_send_frame() (CVE-2023-52907 bsc#1229526).
- commit 462fb2b

- wifi: mac80211: sdata can be NULL during AMPDU start
  (CVE-2022-48875 bsc#1229516).
- commit 5fb2170

- devres: Fix memory leakage caused by driver API devm_free_percpu() (CVE-2024-43871 bsc#1229490)
- commit 4465aef

- rpm/check-for-config-changes: Exclude ARCH_USING_PATCHABLE_FUNCTION_ENTRY
  gcc version dependent, at least on ppc
- commit 16da158

- s390/pkey: Use kfree_sensitive() to fix Coccinelle warnings
  (CVE-2024-42158 bsc#1228720).
- commit 13ea3b5

- af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg
  (bsc#1226846 CVE-2024-38596).
- Update
  patches.suse/af_unix-Fix-data-races-around-sk-sk_shutdown.patch
  (git-fixes bsc#1226846).
- commit a35b43b

- RDMA/hns: Fix soft lockup under heavy CEQE load (bsc#1229489 CVE-2024-43872)
- commit 8bd84db

- ipv6: sr: fix memleak in seg6_hmac_init_algo (CVE-2024-39489 bsc#1227623)
- commit 9c4fab9

- usb: xhci: prevent potential failure in handle_tx_event()
  for Transfer events without TRB (CVE-2024-42226 bsc#1228709).
- commit e6525c1

- usb: gadget: configfs: Prevent OOB read/write in
  usb_string_copy() (CVE-2024-42236 bsc#1228964).
- commit bf495b3

- USB: serial: mos7840: fix crash on resume (CVE-2024-42244
  bsc#1228967).
- commit c904d0e

- wifi: cfg80211: handle 2x996 RU allocation in
  cfg80211_calculate_bitrate_he() (CVE-2024-43879 bsc#1229482).
- commit 8fe6121

- kABI: tpm-interface: Hide new include from genksyms
  (bsc#1082555).
- commit d46dd8a

- cpufreq: schedutil: Use kobject release() method to free sugov_tunables (CVE-2021-47387 bsc#1225316)
  CVE backport so remove it from blacklist.conf, added in 56273cd113da0c
  (&amp;quot;blacklist.conf: Fix to experimental feature, fix only in the event of
  a customer bug&amp;quot;).
- commit 074afac

- netfilter: nf_tables: fix memleak in map from abort path
  (CVE-2024-27011 bsc#1223803).
- commit 5b46784

- Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()
  (bsc#1225578 CVE-2024-36013).
- commit 12a50ad

- filelock: Fix fcntl/close race recovery compat path (bsc#1228427
  CVE-2024-41020).
- commit 0ef50b1

- filelock: Remove locks reliably when fcntl/close race is
  detected (bsc#1228247 CVE-2024-41012).
- commit c84976c

- netfilter: nft_limit: reject configurations that cause integer
  overflow (CVE-2024-26668 bsc#1222335).
- commit 0c4fd3e

- netfilter: nft_limit: fix packet ratelimiting (CVE-2024-26668
  bsc#1222335).
- Refresh
  patches.suse/netfilter-nft_limit-avoid-possible-divide-error-in-n.patch.
- commit 045f275

- kvm: s390: Reject memory region operations for ucontrol VMs
  (CVE-2024-43819 bsc#1229290 git-fixes).
- commit e43e818

- s390/pkey: Wipe sensitive data on failure (CVE-2024-42157
  bsc#1228727 git-fixes).
- commit 323dd0d

- irqdomain: Fixed unbalanced fwnode get and put (git-fixes).
- genirq/generic_chip: Make irq_remove_generic_chip() irqdomain
  aware (git-fixes).
- genirq/ipi: Fix NULL pointer deref in
  irq_data_get_affinity_mask() (git-fixes).
- irqdomain: Fix domain registration race (git-fixes).
- irqdomain: Fix mapping-creation race (git-fixes).
- irqdomain: Refactor __irq_domain_alloc_irqs() (git-fixes).
- irqdomain: Look for existing mapping only once (git-fixes).
- irqdomain: Drop bogus fwspec-mapping error handling (git-fixes).
- irqdomain: Fix association race (git-fixes).
- genirq/irqdesc: Don't try to remove non-existing sysfs files
  (git-fixes).
- genirq/msi: Ensure deactivation on teardown (git-fixes).
- genirq/msi: Activate Multi-MSI early when
  MSI_FLAG_ACTIVATE_EARLY is set (git-fixes).
- genirq/irqdomain: Check pointer in
  irq_domain_alloc_irqs_hierarchy() (git-fixes).
- genirq/proc: Reject invalid affinity masks (again) (git-fixes).
- genirq: Delay deactivation in free_irq() (git-fixes).
- kABI: genirq: Delay deactivation in free_irq() (kabi git-fixes).
- genirq: Make sure the initial affinity is not empty (git-fixes).
- commit 37becc8

- KVM: mmio: Fix use-after-free Read in
  kvm_vm_ioctl_unregister_coalesced_mmio (CVE-2021-47341
  bsc#1224923).
- commit 12d646d

- bna: adjust 'name' buf size of bna_tcb and bna_ccb structures
  (CVE-2024-43839 bsc#1229301).
- commit 5a42d4e

- efi: runtime: avoid EFIv2 runtime services on Apple x86 machines
  (bsc#1226629 CVE-2022-48769).
- commit 88b4118

- dma: fix call order in dmam_free_coherent (bsc#1229346
  CVE-2024-43856).
- commit b96a5fb

- netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu() (CVE-2024-36286 bsc#1226801)
- commit 3ee11b6

- netfilter: tproxy: bail out if IP has been disabled on the device (CVE-2024-36270 1226798)
- commit d5e958c

- netfilter: nf_conntrack_h323: Add protection for bmp length out of range (CVE-2024-26851 bsc#1223074)
  Previous four patches fix other bound check bugs or prepare code for
  this to apply cleanly.
- commit ca9c856

- netfilter: nf_conntrack_h323: restore boundary check correctness (bsc#1223074)
- commit a87a86d

- netfilter: nf_ct_h323: Extend nf_h323_error_boundary to work on bits as well (bsc#1223074)
- commit 034ab36

- netfilter: nf_ct_h323: Convert CHECK_BOUND macro to function (bsc#1223074)
- commit f812de4

- netfilter: nf_ct_h323: Out Of Bound Read in Netfilter Conntrack (bsc#1223074)
- commit b7e85f6

- ACPICA: Revert &amp;quot;ACPICA: avoid Info: mapping multiple BARs. Your
  kernel is fine.&amp;quot; (bsc#1227820 CVE-2024-40984).
- commit cc6eb03

- scsi: target: core: Silence the message about unknown VPD pages
  (bsc#1221252 bsc#1229462).
- commit 73ee6e7

- mISDN: Fix a use after free in hfcmulti_tx() (CVE-2024-42280 bsc#1229388)
- commit e5565c3

- tipc: Return non-zero value from tipc_udp_addr2str() on error (CVE-2024-42284 bsc#1229382)
- commit 4d8536f

- sysctl: always initialize i_uid/i_gid (CVE-2024-42312 bsc#1229357)
- commit b5674a1

- drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes (CVE-2024-42310 bsc#1229358)
- commit ac17234

- drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes (CVE-2024-42309 bsc#1229359)
- commit 452c306

- block: initialize integrity buffer to zero before writing it to media (CVE-2024-43854 bsc#1229345)
- commit 2414013

- ipvs: properly dereference pe in ip_vs_add_service (CVE-2024-42322 bsc#1229347)
- commit 3e24abe

- dev/parport: fix the array out-of-bounds risk (CVE-2024-42301
  bsc#1229407).
- commit b4a682d

- RDMA/iwcm: Fix a use-after-free related to destroying CM IDs (bsc#1229381 CVE-2024-42285)
- commit b6331d8

- arm64: ACPI: NUMA: initialize all values of acpi_early_node_map to (git-fixes)
- commit c501ca8

- media: mediatek: vcodec: Handle invalid decoder vsi
  (CVE-2024-43831 bsc#1229309).
- commit 38f48e2

- fuse: Initialize beyond-EOF page contents before setting
  uptodate (bsc#1229457).
- commit 7188cb3

- bpf: Fix a segment issue when downgrading gso_size (bsc#1229386
  CVE-2024-42281).
- commit 4edf813

- Refresh
  patches.suse/bpf-fix-bpf_skb_adjust_net-bpf_skb_proto_xlat-to-dea.patch.
- add hunks that were missing because this patch predates
  patches.suse/bpf-add-bpf_skb_adjust_room-helper.patch
- commit b6ecdd7

- net/iucv: fix use after free in iucv_sock_close()
  (CVE-2024-42271 bsc#1229400 bsc#1228975).
- commit f2f712f

- Refresh sorted patches.
- Refresh patches.suse/cpu-SMT-Enable-SMT-only-if-a-core-is-online.patch.
- Refresh patches.suse/powerpc-topology-Check-if-a-core-is-online.patch.
- commit 1b405bb

- Update patches.suse/cpu-SMT-Enable-SMT-only-if-a-core-is-online.patch
  (bsc#1214285 bsc#1205462 ltc#200161 ltc#200588 git-fixes
  bsc#1229327 ltc#206365).
- Update patches.suse/powerpc-topology-Check-if-a-core-is-online.patch
  (bsc#1214285 bsc#1205462 ltc#200161 ltc#200588 git-fixes
  bsc#1229327 ltc#206365).
- commit a8be45e

- gss_krb5: Fix the error handling path for
  crypto_sync_skcipher_setkey (git-fixes).
- commit 6e52103

- ALSA: timer: Relax start tick time check for slave timer
  elements (git-fixes CVE-2024-38618 bsc#1226754).
- commit de27c4e

- USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor (CVE-2024-41035 bsc#1228485)
- commit 456ee09

- s390/uv: Panic for set and remove shared access UVC errors
  (git-fixes bsc#1229229).
- commit 172448f

- gve: Account for stopped queues when reading NIC stats
  (CVE-2024-42162 bsc#1228706).
- commit 7acbc65

- net: mana: Fix race on per-CQ variable napi work_done
  (bsc#1229154).
- Refresh
  patches.suse/net-mana-Configure-hwc-timeout-from-hardware.patch.
- commit d7d72be

- net: mana: Fix doorbell out of order violation and avoid
  unnecessary doorbell rings (bsc#1229154).
- commit 72d0bd1

- KVM: s390: Do not report unusabled IDs via KVM_CAP_MAX_VCPU_ID
  (git-fixes bsc#1229222).
- commit 590a719

- mmc: mmc_spi: fix error handling in mmc_spi_probe() (bsc#1225483
  CVE-2023-52708).
- commit c7ef14e

- sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl
  (bsc#1225508 CVE-2021-47549).
- commit ed3ad9e

- irqchip/gic-v3-its: Fix potential VPE leak on error (bsc#1225190
  CVE-2021-47373).
- commit c95f6d5

- i2c: acpi: fix resource leak in reconfiguration device addition
  (bsc#1225223 CVE-2021-47425).
- commit 61ff581

- nfc: nci: Fix handling of zero-length payload packets in
  nci_rx_work() (git-fixes).
- nfc: nci: Fix uninit-value in nci_rx_work (git-fixes).
- nfc: nci: Fix kcov check in nci_rx_work() (git-fixes).
- commit b2f9141

- net, sunrpc: Remap EPERM in case of connection failure in
  xs_tcp_setup_socket (CVE-2024-42246 bsc#1228989).
- Refresh
  patches.suse/SUNRPC-improve-swap-handling-scheduling-and-PF_MEMAL.patch.
- commit 135ee65

- powerpc/topology: Check if a core is online (bsc#1214285
  bsc#1205462 ltc#200161 ltc#200588 git-fixes).
- cpu/SMT: Enable SMT only if a core is online (bsc#1214285
  bsc#1205462 ltc#200161 ltc#200588 git-fixes).
- commit bf2704c

- ata: libata-core: Fix null pointer dereference on error (CVE-2024-41098 bsc#1228467).
- commit 706447c

- vsock: correct removal of socket from the list (bsc#1227996).
- commit fa0bbe3

- x86/xen: Drop USERGS_SYSRET64 paravirt call (CVE-2021-4440
  bsc#1227069).
- Refresh
  patches.suse/x86-entry_64-Add-VERW-just-before-userspace-transition.patch.
- Refresh
  patches.suse/x86-xen-add-xenpv_restore_regs_and_return_to_usermode.patch.
- commit 8c4b30e

- tcp_metrics: validate source addr length
  (CVE-2024-42154 bsc#1228507).
- commit 21723ca

- memcg: protect concurrent access to mem_cgroup_idr (git-fixes).
- commit 7946225

- x86/pv: Switch SWAPGS to ALTERNATIVE (CVE-2021-4440
  bsc#1227069).
- Refresh patches.suse/x86-Add-magic-AMD-return-thunk.patch.
- Refresh
  patches.suse/x86-entry-add-kernel-ibrs-implementation.patch.
- commit 0ebe004

- vsock: remove vsock from connected table when connect is
  interrupted by a signal (CVE-2022-48786 bsc#1227996).
- commit 1f3fc69

- libceph: fix race between delayed_work() and ceph_monc_stop()
  (bsc#1228959 CVE-2024-42232).
- commit 498ef72

- nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
  (git-fixes CVE-2024-35915 bsc#1224479).
- commit e2eb32a

- rpm/kernel-binary.spec.in: fix klp_symbols macro
  The commit below removed openSUSE filter from %ifs of the klp_symbols
  definition. But it removed -c of grep too and that causes:
  error: syntax error in expression:  01 &amp;amp;&amp;amp; (  || 1 )
  error:                                        ^
  error: unmatched (:  01 &amp;amp;&amp;amp; (  || 1 )
  error:                     ^
  error: kernel-default.spec:137: bad %if condition:  01 &amp;amp;&amp;amp; (  || 1 )
  So reintroduce -c to the PTF's grep.
  Fixes: fd0b293bebaf (kernel-binary.spec.in: Enable klp_symbols on openSUSE Tumbleweed (boo#1229042).)
- commit 4a36fe3

- kernel-binary.spec.in: Enable klp_symbols on openSUSE Tumbleweed (boo#1229042).
  After the Jump project the kernel used by SLE and openSUSE Leap are the
  same. As consequence the klp_symbols variable is set, enabling
  kernel-default-livepatch-devel on both SLE and openSUSE.
  The current rules to avoid enabling the package exclude openSUSE
  Tumbleweed alone, which doesn't makes sense for now. Enabling
  kernel-default-livepatch-devel on TW makes it easier to test the
  creation of kernel livepatches of the next SLE versions.
- commit fd0b293

- Update
  patches.suse/0001-ocfs2-fix-DIO-failure-due-to-insufficient-transactio.patch
  (bsc#1216834 CVE-2024-42077 bsc#1228516).
- Update
  patches.suse/ocfs2-strict-bound-check-before-memcmp-in-ocfs2_xatt.patch
  (bsc#1228410 CVE-2024-41016).
- Update
  patches.suse/usb-atm-cxacru-fix-endpoint-checking-in-cxacru_bind.patch
  (git-fixes CVE-2024-41097 bsc#1228513).
- Update
  patches.suse/x86-bhi-Avoid-warning-in-DB-handler-due-to-BHI-mitigation.patch
  (git-fixes CVE-2024-42240 bsc#1228966).
  Add CVE references.
- commit 97c33e4

- net: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx()
  from __netif_rx() (CVE-2024-42110 bsc#1228501).
- bnx2x: Fix multiple UBSAN array-index-out-of-bounds
  (CVE-2024-42148 bsc#1228487).
- commit 8188617

- inet_diag: Initialize pad field in struct inet_diag_req_v2
  (CVE-2024-42106 bsc#1228493).
- commit 71e61fd

- tipc: fix kernel panic when enabling bearer (CVE-2022-48865
  bsc#1228065).
- commit a0e7a51

- s390/sclp: Fix sclp_init() cleanup on failure (CVE-2024-41068
  bsc#1228579).
- commit 1a2e580

- btrfs: fix processing of delayed tree block refs during backref
  walking (bsc#1228982).
- btrfs: Remove unused op_key var from add_delayed_refs
  (bsc#1228982).
- commit 1382fa0

- tpm: tpm1_bios_measurements_next should increase position index
  (bsc#1082555).
- tpm: access command header through struct in tpm_try_transmit()
  (bsc#1082555).
- commit f79c4b3

- tpm: Prevent hwrng from activating during resume (bsc#1082555).
- tpm: Allow system suspend to continue when TPM suspend fails
  (bsc#1082555).
- tpm: Add a flag to indicate TPM power is managed by firmware
  (bsc#1082555).
- commit 7eb0e28

- kernel-binary: generate and install compile_commands.json (bsc#1228971)
  This file contains the command line options used to compile every C file.
  It's useful for the livepatching team.
- commit 8efe375

- tpm/tpm_crb: Fix error message in __crb_relinquish_locality()
  (bsc#1082555).
- commit a397ffb

- tpm: Revert &amp;quot;tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing
  for interrupts&amp;quot; (bsc#1082555).
- commit b8cd04a

- xdp: Remove WARN() from __xdp_reg_mem_model() (bsc#1228482
  CVE-2024-42082).
- commit 3f265d8

- pinctrl: fix deadlock in create_pinctrl() when handling
  - EPROBE_DEFER (CVE-2024-42090 bsc#1228449).
- commit f210b8f

- packaging: Add case-sensitive perl option parsing
  A recent change in Getopt::Long [1]:
  Changes in version 2.55
  - ----------------------
  * Fix long standing bug that duplicate options were not detected
  when the options differ in case while ignore_case is in effect.
  This will now yield a warning and become a fatal error in a future
  release.
  perl defaults to ignore_case by default, switch it off to avoid
  accidental misparsing of options.
  This was suggested after similar change in scripts/.
- commit e978477

- drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes (CVE-2024-42101 bsc#1228495).
- commit f00bb1f

- drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc (CVE-2024-42228 bsc#1228667).
- commit d4e3f63

- btrfs: send: fix send failure of a subcase of orphan inodes
  (bsc#1228030).
- btrfs: send: fix failures when processing inodes with no links
  (bsc#1228030).
- commit 9fd4ec5

- btrfs: send: use boolean types for current inode status
  (bsc#1228030).
- commit 2ab676b

- btrfs: send: refactor arguments of get_inode_info()
  (bsc#1228030).
- commit 3731717

- kABI: Hide the new last_cc member in a hole in struct tpm_chip
  (bsc#1082555).
- commit fac3e7a

- btrfs: send: always use the rbtree based inode ref management
  infrastructure (bsc#1228030).
- commit 252130e

- btrfs: fix 64bit compat send ioctl arguments not initializing
  version member (bsc#1228030).
- btrfs: fix send ioctl on 32bit with 64bit kernel (bsc#1228030).
- btrfs: send: add new command FILEATTR for file attributes
  (bsc#1228030).
- btrfs: send: add stream v2 definitions (bsc#1228030).
- btrfs: send: avoid copying file data (bsc#1228030).
- btrfs: send: explicitly number commands and attributes
  (bsc#1228030).
- btrfs: send: get rid of i_size logic in send_write()
  (bsc#1228030).
- btrfs: send: prepare for v2 protocol (bsc#1228030).
- btrfs: send: remove unused send_ctx::{total,cmd}_send_size
  (bsc#1228030).
- Refresh
  patches.suse/Btrfs-fix-race-between-send-and-deduplication-that-l.patch.
- Refresh
  patches.suse/btrfs-send-ensure-send_fd-is-writable.patch.
- Refresh
  patches.suse/btrfs-send-fix-sending-link-commands-for-existing-fi.patch.
- commit 956ca27

- x86/bhi: Avoid warning in #DB handler due to BHI mitigation (git-fixes).
- commit f899605

- Refresh patches.suse/IB-hfi1-Fix-bugs-with-non-PAGE_SIZE-end-multi-iovec-.patch
  Alt-commit added
  Blacklist the follow-up fix of the Alt-commit
- commit c3542b0

- ima: Fix use-after-free on a dentry's dname.name (bsc#1227716
  CVE-2024-39494).
- commit 2e3d558

- x86/bugs: Replace CONFIG_SPECTRE_BHI_{ON,OFF} with CONFIG_MITIGATION_SPECTRE_BHI (git-fixes).
- Update config files.
- commit 4549b89

- x86/bugs: Remove CONFIG_BHI_MITIGATION_AUTO and spectre_bhi=auto (git-fixes).
  This commit was missing for SLE12-SP5 which made the performance profile
  of SLE12-SP5 and SLE15-SP[56] differ. Our decision was to follow
  upstream w.r.t how BHI is going to be mitigated and the decision was to
  do away with 'auto' mode.
- Update config files.
- commit 02bfc90

- Sort BHI mitigation patches
- Refresh patches.suse/x86-bhi-Add-BHI-mitigation-knob.patch.
- Refresh
  patches.suse/x86-bhi-Add-support-for-clearing-branch-history-at-syscall.patch.
- Refresh patches.suse/x86-bhi-Define-SPEC_CTRL_BHI_DIS_S.patch.
- Refresh
  patches.suse/x86-bhi-Enumerate-Branch-History-Injection-BHI-bug.patch.
- Refresh patches.suse/x86-bhi-Mitigate-KVM-by-default.patch.
- Refresh
  patches.suse/x86-cpufeature-Add-missing-leaf-enumeration.patch.
- commit f2f0729

- PCI: hv: Return zero, not garbage, when reading
  PCI_INTERRUPT_PIN (git-fixes).
- commit 08ef890

- kABI: do not rename tpm_do_selftest, tpm_pcr_read_dev, and tpm1_getcap
  (bsc#1082555).
- Delete patches.kabi/kABI-Do-not-rename-tpm_getcap.patch
- commit 5a6f1d9

- kABI: Do not rename tpm_getcap (bsc#1082555).
- commit 01263dd

- kABI: re-export tpm2_calc_ordinal_duration (bsc#1082555).
- commit 1303a23

- kABI: Instead of changing the pcr argument type add a local
  variable of the desired type, and assign it from the actual
  argument (bsc#1082555).
- Refresh patches.kabi/kABI-do-not-rename-tpm_do_selftest-tpm_pcr_read_dev-.patch
- commit e919992

- kABI: no need to store the tpm long long duration in tpm_chip
  struct, it is an arbitrary hardcoded value (bsc#1082555).
- commit 75cc28e

- kABI: do not change return type of tpm_tis_update_timeouts
  (bsc#1082555).
- commit 57d9ed9

- Move kABI patch to kABI section.
- commit 3f941d1

- KVM: PPC: Book3S HV: remove extraneous asterisk from
  rm_host_ipi_action() comment (bsc#1065729).
- KVM: PPC: Book3S HV: Don't take kvm-&amp;gt;lock around
  kvm_for_each_vcpu (bsc#1065729).
- KVM: PPC: Book3S: Use new mutex to synchronize access to rtas
  token list (bsc#1065729).
- Refresh patches.suse/KVM-PPC-Book3S-Fix-H_RTAS-rets-buffer-overflow.patch
- KVM: PPC: Book3S: Only report KVM_CAP_SPAPR_TCE_VFIO on powernv
  machines (bsc#1065729).
- KVM: PPC: Move and undef TRACE_INCLUDE_PATH/FILE (bsc#1065729).
- KVM: PPC: Inform the userspace about TCE update failures
  (bsc#1065729).
- KVM: PPC: Book3S PR: Exiting split hack mode needs to fixup
  both PC and LR (bsc#1065729).
- commit ad6fee4

- x86: stop playing stack games in profile_pc() (bsc#1228633
  CVE-2024-42096).
- commit 0bc3d2d

- btrfs: send: remove stale code when checking for shared extents
  (bsc#1228030).
- btrfs: silence maybe-uninitialized warning in clone_range
  (bsc#1228030).
- commit 095e644

- Btrfs: incremental send, fix emission of invalid clone
  operations (bsc#1228030).
- commit 88a98fe

- Btrfs: send, improve clone range (bsc#1228030).
- commit 8a72517

- btrfs: remove unused members dir_path from recorded_ref
  (bsc#1228030).
- Refresh
  patches.suse/btrfs-incremental-send-fix-invalid-path-for-unlink-commands.patch.
- Refresh
  patches.suse/btrfs-send-fix-sending-link-commands-for-existing-fi.patch.
- commit 980e08a

- liquidio: Adjust a NULL pointer handling path in
  lio_vf_rep_copy_packet (CVE-2024-39506 bsc#1227729).
- i40e: Fix queues reservation for XDP (CVE-2021-47619
  bsc#1226645).
- commit 37ce537

- btrfs: send: remove unused found_type parameter to
  lookup_dir_item_inode() (bsc#1228030).
- commit bc238fe

- scsi: qla2xxx: Convert comma to semicolon (bsc#1228850).
- scsi: qla2xxx: Update version to 10.02.09.300-k (bsc#1228850).
- scsi: qla2xxx: Use QP lock to search for bsg (bsc#1228850).
- scsi: qla2xxx: Reduce fabric scan duplicate code (bsc#1228850).
- scsi: qla2xxx: Fix optrom version displayed in FDMI
  (bsc#1228850).
- scsi: qla2xxx: During vport delete send async logout explicitly
  (bsc#1228850).
- scsi: qla2xxx: Complete command early within lock (bsc#1228850).
- scsi: qla2xxx: Fix flash read failure (bsc#1228850).
- scsi: qla2xxx: Return ENOBUFS if sg_cnt is more than one for
  ELS cmds (bsc#1228850).
- scsi: qla2xxx: Fix for possible memory corruption (bsc#1228850).
- scsi: qla2xxx: validate nvme_local_port correctly (bsc#1228850).
- scsi: qla2xxx: Unable to act on RSCN for port online
  (bsc#1228850).
- scsi: qla2xxx: Remove unused struct 'scsi_dif_tuple'
  (bsc#1228850).
- scsi: qla2xxx: Fix debugfs output for fw_resource_count
  (bsc#1228850).
- scsi: qla2xxx: Drop driver owner assignment (bsc#1228850).
- scsi: qla2xxx: Avoid possible run-time warning with long
  model_num (bsc#1228850).
- string.h: Introduce memtostr() and memtostr_pad() (bsc#1228850).
- commit 2402124

- nvme: fixup comment for nvme RDMA Provider Type (git-fixes).
- commit 67b36fc

- check-for-config-changes: ignore also GCC_ASM_GOTO_OUTPUT_BROKEN
  Mainline commit f2f6a8e88717 (&amp;quot;init/Kconfig: remove
  CONFIG_GCC_ASM_GOTO_OUTPUT_WORKAROUND&amp;quot;) replaced
  GCC_ASM_GOTO_OUTPUT_WORKAROUND with GCC_ASM_GOTO_OUTPUT_BROKEN. Ignore both
  when checking config changes.
- commit b60be3e

- IB/core: Implement a limit on UMAD receive List (bsc#1228743 CVE-2024-42145)
- commit 9aa0d29

- Update
  patches.suse/Bluetooth-SCO-Fix-not-validating-setsockopt-user-inp.patch
  (bsc#1224576 CVE-2024-35966 CVE-2024-35967 bsc#1224587).
- Update
  patches.suse/RDMA-mlx5-Add-check-for-srq-max_sge-attribute.patch
  (git-fixes CVE-2024-40990 bsc#1227824).
- Update
  patches.suse/USB-class-cdc-wdm-Fix-CPU-lockup-caused-by-excessive.patch
  (git-fixes CVE-2024-40904 bsc#1227772).
- Update
  patches.suse/ocfs2-fix-races-between-hole-punching-and-AIO-DIO.patch
  (bsc#1227849 CVE-2024-40943).
- Update
  patches.suse/tracing-trigger-Fix-to-return-error-if-failed-to-alloc-snapshot.patch
  (git-fixes CVE-2024-26920 bsc#1228237).
- commit 71c68bc

- Update
  patches.suse/SUNRPC-Fix-UAF-in-svc_tcp_listen_data_ready.patch
  (git-fixes CVE-2023-52885 bsc#1227750).
- commit 4594a5d

- Update
  patches.suse/Input-aiptek-properly-check-endpoint-type.patch
  (git-fixes CVE-2022-48836 bsc#1227989).
- Update
  patches.suse/net-ieee802154-at86rf230-Stop-leaking-skb-s.patch
  (git-fixes CVE-2022-48794 bsc#1228025).
- Update
  patches.suse/net-packet-fix-slab-out-of-bounds-access-in-packet_r.patch
  (CVE-2022-20368 bsc#1202346 CVE-2022-48839 bsc#1227985).
- Update
  patches.suse/net-usb-ax88179_178a-Fix-out-of-bounds-accesses-in-R.patch
  (bsc#1196018 CVE-2022-28748 CVE-2022-2964 CVE-2022-48805
  bsc#1227969).
- commit 55fdbd1

- scsi: qedf: Make qedf_execute_tmf() non-preemptible (CVE-2024-42124 bsc#1228705)
- commit 7bd7589

- media: dvb-frontends: tda10048: Fix integer overflow (CVE-2024-42223 bsc#1228726)
- commit 4d685fd

- drm/amd/display: Skip finding free audio for unknown engine_id (CVE-2024-42119 bsc#1228584)
- commit f0a5549

- drm/amd/display: Check pipe offset before setting vblank (CVE-2024-42120 bsc#1228588)
- commit d85398e

- drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes (CVE-2024-41095 bsc#1228662)
- commit bb0cd8f

- btrfs: send: fix sending link commands for existing file paths
  (bsc#1228030).
- commit 5a1f564

- net: dsa: mv88e6xxx: Correct check for empty list (CVE-2024-42224 bsc#1228723)
- commit f7ea584

- wifi: cfg80211: wext: add extra SIOCSIWSCAN data check (CVE-2024-41072 bsc#1228626)
- commit c131ba5

- bpf, sockmap: Fix partial copy_page_to_iter so progress can still be made (CVE-2024-41048 bsc#1228565)
- commit 79dff63

- skmsg: Skip zero length skb in sk_msg_recvmsg (CVE-2024-41048 bsc#1228565)
  Based on c9c89dcd872e (&amp;quot;bpf, sockmap: Fix partial copy_page_to_iter so
  progress can still be made&amp;quot;), previous commit.
  Upstream commit 2bc793e3272a13 (&amp;quot;skmsg: Extract __tcp_bpf_recvmsg() and
  tcp_bpf_wait_data()&amp;quot;) moved the code from net/ipv4/tcp_bpf.c to
  net/core/skmsg.c.
- commit 80be5ae

- net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()
  (CVE-2024-40995 bsc#1227830).
- commit ee1ce8a

- btrfs: send: introduce recorded_ref_alloc and recorded_ref_free
  (bsc#1228030).
- commit 2f5e245

- cgroup/cpuset: Prevent UAF in proc_cpuset_show() (bsc#1228801).
- commit e47e175

- ppp: reject claimed-as-LCP but actually malformed packets
  (CVE-2024-41044 bsc#1228530).
- ibmvnic: Add tx check to prevent skb leak (CVE-2024-41066
  bsc#1228640).
- commit 0bdb098

- net/dpaa2: Avoid explicit cpumask var allocation on stack
  (CVE-2024-42093 bsc#1228680).
- dpaa2-eth: Refactor xps code (CVE-2024-42093 bsc#1228680).
- commit caf72f9

- drm/nouveau/dispnv04: fix null pointer dereference in (bsc#1228658 CVE-2024-41089)
- commit aec5d0e

- drm/radeon: check bo_va-&amp;gt;bo is non-NULL before using it (bsc#1228567 CVE-2024-41060)
- commit 7a28cea

- NFSD: Fix NFSv3 SETATTR/CREATE's handling of large file sizes
  (CVE-2022-48829 bsc#1228055).
- NFSD: Fix ia_size underflow (CVE-2022-48828 bsc#1228054).
- NFSD: Fix the behavior of READ near OFFSET_MAX (CVE-2022-48827
  bsc#1228037).
- commit 1c127f3

- btrfs: qgroup: fix quota root leak after quota disable failure
  (bsc#1228655 CVE-2024-41078).
- commit 263e74a

- wifi: mac80211: Avoid address calculations via out of bounds
  array indexing (CVE-2024-41071 bsc#1228625).
- commit be2129f

- powerpc/eeh: avoid possible crash when edev-&amp;gt;pdev changes
  (CVE-2024-41064 bsc#1228599).
- commit 145d8ea

- btrfs: make sure that WRITTEN is set on all metadata blocks (CVE-2024-35949 bsc#1224700)
  Changes: adjust returned error codes to -EUCLEAN and drop definition of
  the enum error.
- commit 6dc890d

- ila: block BH in ila_output() (CVE-2024-41081 bsc#1228617)
- commit 9ec349b

- scsi: qedi: Fix crash while reading debugfs attribute
  (bsc#1227929 CVE-2024-40978).
- scsi: pm8001: Fix use-after-free for aborted SSP/STP sas_task
  (bsc#1228013 CVE-2022-48792).
- scsi: qedf: Fix refcount issue when LOGO is received during TMF
  (bsc#1228045 CVE-2022-48823).
- commit 2a5c419

- ext4: fix uninitialized ratelimit_state-&amp;gt;lock access in
  __ext4_fill_super() (bsc#1227866 CVE-2024-40998).
- commit 5fe487a

- hfsplus: fix uninit-value in copy_name (bsc#1228561
  CVE-2024-41059).
- commit 8d75c30

- usb: musb: da8xx: fix a resource leak in probe() (git-fixes).
- commit bc4c361

- usb: atm: cxacru: fix endpoint checking in cxacru_bind()
  (git-fixes).
- commit c9a5140

- USB: class: cdc-wdm: Fix CPU lockup caused by excessive log
  messages (git-fixes).
- commit 7c21caa

- drm/amdgpu: fix UBSAN warning in kv_dpm.c (bsc#1228235 CVE-2024-40987)
- commit 60606a5

- drm/vc4: Fix deadlock on DSI device attach error (bsc#1227975 CVE-2022-48826)
- commit bcda77c

- drm/vc4: dsi: Only register our component once a DSI device is (bsc#1227975)
- commit 0a73252

- genirq: Add IRQF_NO_AUTOEN for request_irq/nmi() (bsc#1222625
  CVE-2024-27437).
- commit 351bbe3

- ocfs2: add bounds checking to ocfs2_check_dir_entry()
  (bsc#1228409 CVE-2024-41015).
- ocfs2: strict bound check before memcmp in
  ocfs2_xattr_find_entry() (bsc#1228410).
- ocfs2: add bounds checking to ocfs2_xattr_find_entry()
  (bsc#1228410 CVE-2024-41016).
- ocfs2: remove redundant assignment to variable free_space
  (bsc#1228409).
- commit 2a658bc

- vfio/pci: Disable auto-enable of exclusive INTx IRQ (bsc#1222625
  CVE-2024-27437).
- commit 9829ce8

- Fix reference in patches.suse/ixgbe-Fix-NULL-pointer-dereference-in-ixgbe_xdp_setu.patch (CVE-2021-47399 bsc#1225328)
- commit 7933225

- ocfs2: fix DIO failure due to insufficient transaction credits
  (bsc#1216834).
- commit e4fdc60

- Bluetooth: hci_core: cancel all works upon hci_unregister_dev() (CVE-2024-41063 bsc#1228580)
- commit 95070bc

- netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers (CVE-2024-42070 bsc#1228470)
- commit d9e81e6

- KVM: PPC: Book3S: Fix some RCU-list locks (git-fixes).
- commit e20a5cb

- KVM: PPC: Book3S HV: Prevent UAF in
  kvm_spapr_tce_attach_iommu_group() (bsc#1228581 CVE-2024-41070).
- commit 1cd5894

- tpm: use tpm_msleep() value as max delay (bsc#1082555).
- Refresh patches.suse/tpm-use-struct-tpm_chip-for-tpm_chip_find_get.patch
- commit fd76767

- tpm_tis: Resend command to recover from data transfer errors
  (bsc#1082555).
- tpm_tis: Explicitly check for error code (bsc#1082555).
- tpm: tpm_vtpm_proxy: fix a race condition in /dev/vtpmx creation
  (bsc#1082555).
- tpm, tpm_tis: correct tpm_tis_flags enumeration values
  (bsc#1082555).
- tpm_tis: Use tpm_chip_{start,stop} decoration inside
  tpm_tis_resume (bsc#1082555).
- tpm, tpm_tis: Claim locality when interrupts are reenabled on
  resume (bsc#1082555).
- tpm, tpm: Implement usage counter for locality (bsc#1082555).
- tpm, tpm_tis: Only handle supported interrupts (bsc#1082555).
- tpm, tpm_tis: Claim locality before writing interrupt registers
  (bsc#1082555).
- tpm, tpm_tis: Do not skip reset of original interrupt vector
  (bsc#1082555).
- tpm, tpm_tis: Disable interrupts if tpm_tis_probe_irq() failed
  (bsc#1082555).
- tpm, tpm_tis: Claim locality before writing TPM_INT_ENABLE
  register (bsc#1082555).
- tpm, tpm_tis: Avoid cache incoherency in test for interrupts
  (bsc#1082555).
- tpm: tpm_tis: Add the missed acpi_put_table() to fix memory leak
  (bsc#1082555).
- tpm: tpm_crb: Add the missed acpi_put_table() to fix memory leak
  (bsc#1082555).
- char: tpm: Protect tpm_pm_suspend with locks (bsc#1082555).
- tpm: Fix buffer access in tpm2_get_tpm_pt() (bsc#1082555).
- tpm: Fix error handling in async work (bsc#1082555).
- tpm: fix NPE on probe for missing device (bsc#1082555).
- tpm_tis: Fix an error handling path in 'tpm_tis_core_init()'
  (bsc#1082555).
- tpm: fix Atmel TPM crash caused by too frequent queries
  (bsc#1082555).
- tpm: Replace WARN_ONCE() with dev_err_once() in tpm_tis_status()
  (bsc#1082555).
- tpm, tpm_tis: Reserve locality in tpm_tis_resume()
  (bsc#1082555).
- tpm, tpm_tis: Extend locality handling to TPM2 in
  tpm_tis_gen_interrupt() (bsc#1082555).
- tpm: vtpm_proxy: Avoid reading host log when using a virtual
  device (bsc#1082555).
- tpm, tpm_tis: Decorate tpm_tis_gen_interrupt() with
  request_locality() (bsc#1082555).
- tpm, tpm_tis: Decorate tpm_get_timeouts() with
  request_locality() (bsc#1082555).
- tpm: Remove tpm_dev_wq_lock (bsc#1082555).
- tpm_tis: Add a check for invalid status (bsc#1082555).
- kABI: tpm2-space: Do not add buf_size to struct tpm_space
  (bsc#1082555).
- tpm: Unify the mismatching TPM space buffer sizes (bsc#1082555).
- Refresh patches.suse/tpm-fix-reference-counting-for-struct-tpm_chip.patch
- tpm: Fix TIS locality timeout problems (bsc#1082555).
- tpm: Handle negative priv-&amp;gt;response_len in tpm_common_read()
  (bsc#1082555).
- tpm: Revert &amp;quot;tpm_tis_core: Turn on the TPM before probing IRQ's&amp;quot;
  (bsc#1082555).
- tpm: Revert &amp;quot;tpm_tis: reserve chip for duration of
  tpm_tis_core_init&amp;quot; (bsc#1082555).
- Refresh patches.suse/tpm_tis-extra-chip-ops-check-on-error-path-in-tpm_ti.patch
- tpm: fix invalid locking in NONBLOCKING mode (bsc#1082555).
- tpm_tis: reserve chip for duration of tpm_tis_core_init
  (bsc#1082555).
- Refresh patches.suse/tpm_tis-extra-chip-ops-check-on-error-path-in-tpm_ti.patch
- tpm: Wrap the buffer from the caller to tpm_buf in tpm_send()
  (bsc#1082555).
- tpm_tis_core: Turn on the TPM before probing IRQ's
  (bsc#1082555).
- Refresh patches.suse/tpm_tis_core-Set-TPM_CHIP_FLAG_IRQ-before-probing-fo.patch
- tpm: Fix null pointer dereference on chip register error path
  (bsc#1082555).
- tpm: Actually fail on TPM errors during &amp;quot;get random&amp;quot;
  (bsc#1082555).
- tpm: fix an invalid condition in tpm_common_poll (bsc#1082555).
- tpm: turn on TPM on suspend for TPM 1.x (bsc#1082555).
- tpm: remove @flags from tpm_transmit() (bsc#1082555).
- Refresh patches.suse/tpm-Fix-TPM-1.2-Shutdown-sequence-to-prevent-future-.patch
- Refresh patches.suse/tpm-add-request_locality-before-write-TPM_INT_ENABLE.patch
- Refresh patches.suse/tpm-fix-potential-NULL-pointer-access-in-tpm_del_cha.patch
- Refresh patches.kabi/kABI-Instead-of-changing-the-pcr-argument-type-add-a.patch
- tpm: take TPM chip power gating out of tpm_transmit()
  (bsc#1082555).
- Refresh patches.suse/tpm-Fix-TPM-1.2-Shutdown-sequence-to-prevent-future-.patch
- Refresh patches.suse/tpm-add-request_locality-before-write-TPM_INT_ENABLE.patch
- Refresh patches.suse/tpm-fix-potential-NULL-pointer-access-in-tpm_del_cha.patch
- tpm: introduce tpm_chip_start() and tpm_chip_stop()
  (bsc#1082555).
- tpm: remove TPM_TRANSMIT_UNLOCKED flag (bsc#1082555).
- tpm: use tpm_try_get_ops() in tpm-sysfs.c (bsc#1082555).
- tpm: remove @space from tpm_transmit() (bsc#1082555).
- tpm: move TPM space code out of tpm_transmit() (bsc#1082555).
- tpm: move tpm_validate_commmand() to tpm2-space.c (bsc#1082555).
- Refresh patches.suse/tpm-fix-reference-counting-for-struct-tpm_chip.patch
- tpm: clean up tpm_try_transmit() error handling flow
  (bsc#1082555).
- tpm: encapsulate tpm_dev_transmit() (bsc#1082555).
- tpm: declare struct tpm_header (bsc#1082555).
- Refresh patches.suse/tpm-fix-reference-counting-for-struct-tpm_chip.patch
- tpm: print tpm2_commit_space() error inside tpm2_commit_space()
  (bsc#1082555).
- Refresh patches.suse/tpm-fix-reference-counting-for-struct-tpm_chip.patch
- tpm: return 0 from pcrs_show() when tpm1_pcr_read() fails
  (bsc#1082555).
- tpm: fix invalid return value in pubek_show() (bsc#1082555).
- tpm: use tpm_buf in tpm_transmit_cmd() as the IO parameter
  (bsc#1082555).
- tpm: don't return bool from update_timeouts (bsc#1082555).
- tpm: add support for partial reads (bsc#1082555).
- tpm: use u32 instead of int for PCR index (bsc#1082555).
- Refresh patches.kabi/kABI-do-not-rename-tpm_do_selftest-tpm_pcr_read_dev-.patch
- tpm1: reimplement tpm1_continue_selftest() using tpm_buf
  (bsc#1082555).
- tpm1: reimplement SAVESTATE using tpm_buf (bsc#1082555).
- tpm1: rename tpm1_pcr_read_dev to tpm1_pcr_read() (bsc#1082555).
- Refresh patches.kabi/kABI-do-not-rename-tpm_do_selftest-tpm_pcr_read_dev-.patch
- tpm1: implement tpm1_pcr_read_dev() using tpm_buf structure
  (bsc#1082555).
- tpm: tpm1: rewrite tpm1_get_random() using tpm_buf structure
  (bsc#1082555).
- tpm: add tpm_auto_startup() into tpm-interface.c (bsc#1082555).
- tpm: factor out tpm_startup function (bsc#1082555).
- tpm: factor out tpm 1.x pm suspend flow into tpm1-cmd.c
  (bsc#1082555).
- Refresh patches.kabi/kABI-do-not-rename-tpm_do_selftest-tpm_pcr_read_dev-.patch
- tpm: move tpm 1.x selftest code from tpm-interface.c tpm1-cmd.c
  (bsc#1082555).
- Refresh patches.kabi/kABI-Do-not-rename-tpm_getcap.patch
- tpm: factor out tpm1_get_random into tpm1-cmd.c (bsc#1082555).
- Refresh patches.kabi/kABI-Do-not-rename-tpm_getcap.patch
- tpm: move tpm_getcap to tpm1-cmd.c (bsc#1082555).
- tpm: move tpm1_pcr_extend to tpm1-cmd.c (bsc#1082555).
- tpm: factor out tpm_get_timeouts() (bsc#1082555).
- Refresh patches.kabi/kABI-no-need-to-store-the-tpm-long-long-duration-in-.patch
- tpm: add tpm_calc_ordinal_duration() wrapper (bsc#1082555).
- tpm: factor out tpm 1.x duration calculation to tpm1-cmd.c
  (bsc#1082555).
- tpm: add support for nonblocking operation (bsc#1082555).
- Refresh patches.suse/tpm-fix-reference-counting-for-struct-tpm_chip.patch
- tpm: add ptr to the tpm_space struct to file_priv (bsc#1082555).
- tpm: replace TPM_TRANSMIT_RAW with TPM_TRANSMIT_NESTED
  (bsc#1082555).
- tpm: rename tpm_chip_find_get() to tpm_find_get_ops()
  (bsc#1082555).
- tpm: migrate tpm2_get_random() to use struct tpm_buf
  (bsc#1082555).
- Refresh patches.suse/tpm-fix-response-size-validation-in-tpm_get_random.patch
- tpm: migrate tpm2_get_tpm_pt() to use struct tpm_buf
  (bsc#1082555).
- tpm: migrate tpm2_probe() to use struct tpm_buf (bsc#1082555).
- tpm: migrate tpm2_shutdown() to use struct tpm_buf
  (bsc#1082555).
- tpm2: add longer timeouts for creation commands (bsc#1082555).
- tpm: fix buffer type in tpm_transmit_cmd (bsc#1082555).
- tpm: migrate pubek_show to struct tpm_buf (bsc#1082555).
- tpm: vtpm_proxy: Prevent userspace from sending driver command
  (bsc#1082555).
- tpm, tpmrm: Mark tpmrm_write as static (bsc#1082555).
- tpm: remove struct tpm_pcrextend_in (bsc#1082555).
- Refresh patches.suse/tpm-consolidate-the-TPM-startup-code.patch
- tpm: fix byte order related arithmetic inconsistency in
  tpm_getcap() (bsc#1082555).
- Refresh patches.suse/tpm-consolidate-the-TPM-startup-code.patch
- tpm: move TPM 1.2 code of tpm_pcr_extend() to tpm1_pcr_extend()
  (bsc#1082555).
- Refresh patches.suse/tpm-use-struct-tpm_chip-for-tpm_chip_find_get.patch
- commit 989dcf1

- rpm/guards: fix precedence issue with control flow operator
  With perl 5.40 it report the following error on rpm/guards script:
  Possible precedence issue with control flow operator (exit) at scripts/guards line 208.
  Fix the issue by adding parenthesis around ternary operator.
- commit 07b8b4e

- HID: usbhid: free raw_report buffers in usbhid_stop (bsc#1225238
  CVE-2021-47405).
- commit 67ff2bd

- drm/radeon: fix UBSAN warning in kv_dpm.c (bsc#1227957 CVE-2024-40988)
- commit 4f641c6

- drm/exynos/vidi: fix memory leak in .get_modes() (bsc#1227828 CVE-2024-40932)
- commit d694b72

- ipack: ipoctal: fix module reference leak (bsc#1225241
  CVE-2021-47403).
- commit 3f2bac7

- mac80211: fix use-after-free in CCMP/GCMP RX (bsc#1225214
  CVE-2021-47388).
- commit 180ca41

- xfs: refactor xfs_verifier_error and xfs_buf_ioerror
  (git-fixes).
- Refresh
  patches.suse/xfs-don-t-ever-return-a-stale-pointer-from-__xfs_dir.patch.
- commit ac4dc1f

- xfs: remove XFS_WANT_CORRUPTED_RETURN from dir3 data verifiers
  (git-fixes).
- commit 5d31a73

- xfs: check that dir block entries don't off the end of the
  buffer (git-fixes).
- commit 46f96de

- xfs: add bounds checking to xlog_recover_process_data
  (bsc#1228408 CVE-2024-41014).
- commit b3db770

- tun: add missing verification for short frame (CVE-2024-41091
  bsc#1228327).
- tap: add missing verification for short frame (CVE-2024-41090
  bsc#1228328).
- net: ena: Add validation for completion descriptors consistency
  (CVE-2024-40999 bsc#1227913).
- net: mvpp2: clear BM pool before initialization (CVE-2024-35837
  bsc#1224500).
- commit 69b68ee

- Update
  patches.suse/xhci-Fix-incorrect-tracking-of-free-space-on-transfe.patch.
  Fix a backporting mistake which was causing the following warning:
  drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
  drivers/usb/host/xhci-ring.c:3255:6: warning: unused variable 'trbs_freed' [-Wunused-variable]
- commit 787d888

- xhci: Poll for U0 after disabling USB2 LPM (git-fixes).
- commit c66374c

- sit: do not call ipip6_dev_free() from sit_init_net()
  (CVE-2021-47588 bsc#1226568).
- commit 9afcbd9

- ipv6: sr: fix incorrect unregister order (git-fixes).
- commit 9f9395f

- Refresh
  patches.suse/powerpc-rtas-Prevent-Spectre-v1-gadget-construction-.patch.
- commit af33133

- vt_ioctl: fix array_index_nospec in vt_setactivate
  (CVE-2022-48804 bsc#1227968).
- commit ee44df4

- serial: imx: Introduce timeout when waiting on transmitter empty
  (CVE-2024-40967 bsc#1227891).
- commit 9b7db88

- kABI: tty: add the option to have a tty reject a new ldisc
  (kabi CVE-2024-40966 bsc#1227886).
- tty: add the option to have a tty reject a new ldisc
  (CVE-2024-40966 bsc#1227886).
- commit 16b4088

- net-sysfs: add check for netdevice being present to speed_show (CVE-2022-48850 bsc#1228071)
- commit 9fdf37b

- Update
  patches.suse/scsi-scsi_debug-Fix-out-of-bound-read-in-resp_report_tgtpgs.patch
  (bsc#1222824 CVE-2021-47219).
  Fix incorrect Bug number and incorrect CVE number.
- commit b4dbf5c

- Update
  patches.suse/scsi-lpfc-Release-hbalock-before-calling-lpfc_worker_wake_up.patch
  (bsc#1225820 CVE-2024-36924).
  Fix incorrect CVE number.
- commit cb94423

- Update
  patches.suse/nvme-rdma-remove-redundant-reference-between-ib_devi.patch
  (bsc#1149446).
  Fix bug reference (missing digit).
- commit 4f5320f

- Update patches.suse/ovl-fix-failure-to-fsync-lower-dir.patch
  (bsc#1088701).
  Fix bug reference (missing digit).
- commit 718aec5

- usb: core: Don't hold the device lock while sleeping in
  do_proc_control() (CVE-2021-47582 bsc#1226559).
- commit ff00ceb

- USB: usbfs: fix mmap dma mismatch (CVE-2021-47582 bsc#1226559).
- commit 6c5305a

- usb: add a hcd_uses_dma helper (git-fixes).
- commit f8aa53d

- ssb: Fix potential NULL pointer dereference in
  ssb_device_uevent() (CVE-2024-40982 bsc#1227865).
- commit 9fbb468

- isdn: mISDN: Fix sleeping function called from invalid context
  (bsc#1225346 CVE-2021-47468).
- commit 34167c4

- mac80211: limit injected vht mcs/nss in
  ieee80211_parse_tx_radiotap (bsc#1225326 CVE-2021-47395).
- commit 2fdeaab

- tools lib: Fix builds when glibc contains strlcpy() (git-fixes).
- blacklist.conf: unblaclist it
  This commit allows for local builds with newer glibc.
- commit 480e775

- PCI: Fix resource double counting on remove &amp;amp; rescan
  (git-fixes).
- commit 68ca613

- ipmr,ip6mr: acquire RTNL before calling ip[6]mr_free_table()
  on failure path (CVE-2022-48810 bsc#1227936).
- commit 7af1a4f

- wifi: ath9k: Fix potential array-index-out-of-bounds read in
  ath9k_htc_txstatus() (CVE-2023-52594 bsc#1221045).
- commit d04a718

- sctp: fix kernel-infoleak for SCTP sockets (CVE-2022-48855
  bsc#1228003).
- commit 5317e78

- scsi: scsi_debug: Fix out-of-bound read in resp_report_tgtpgs()
  (bsc#1226550 CVE-2021-47580).
- commit 72ff240

- ipv6: sr: fix possible use-after-free and null-ptr-deref
  (bsc#1222372 CVE-2024-26735).
- commit 5258c5a

- signal: Introduce clear_siginfo (git-fixes).
- commit 276fe89

- Update
  patches.suse/scsi-scsi_debug-Fix-type-in-min_t-to-avoid-stack-OOB.patch
  (bsc#1226550 CVE-2021-47580).
  Fix incorrect bug#
- commit a8e747b

- scsi: bfa: Ensure the copied buf is NUL terminated (bsc#1226786
  CVE-2024-38560).
- commit 2623515

- ibmvnic: don't release napi in __ibmvnic_open() (bsc#1227928
  CVE-2022-48811).
- commit b1dc7a1

- Update References
  patches.suse/Bluetooth-SMP-Fail-if-remote-and-local-public-keys-a.patch
  (bsc#1186463, CVE-2021-0129, CVE-2020-26558, bsc#1179610,
  CVE-2020-26558).
- commit ef3041a

- gve: Clear napi-&amp;gt;skb before dev_kfree_skb_any() (CVE-2024-40937
  bsc#1227836).
- net: hns3: fix kernel crash problem in concurrent scenario
  (CVE-2024-39507 bsc#1227730).
- ibmvnic: don't release napi in __ibmvnic_open() (CVE-2022-48811
  bsc#1227928).
- commit 753a87a

- Refresh
  patches.suse/ipv6-sr-fix-missing-sk_buff-release-in-seg6_input_co.patch.
  Fix broken patch, which only applys with rapidquilt but not with normal
  patch.
- commit 9ba3403

- vmxnet3: disable rx data ring on dma allocation failure
  (CVE-2024-40923 bsc#1227786).
- commit 4f3a9e9

- wifi: iwlwifi: mvm: don't read past the mfuart notifcation
  (git-fixes CVE-2024-40941 bsc#1227771).
- commit e4b5384

- ethernet: Fix error handling in xemaclite_of_probe (CVE-2022-48860 bsc#1228008)
- commit f50353a

- Bluetooth: RFCOMM: Fix not validating setsockopt user input
  (bsc#1224576 CVE-2024-35966).
- commit 68cb9dc

- mISDN: Fix memory leak in dsp_pipeline_build() (CVE-2022-48863
  bsc#1228063).
- commit 98e043d

- KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()
  (CVE-2024-40953, bsc#1227806).
- commit b18a093

- vmci: prevent speculation leaks by sanitizing event in event_deliver() (CVE-2024-39499 bsc#1227725)
- commit d42ba53

- HID: core: remove unnecessary WARN_ON() in implement() (CVE-2024-39509 bsc#1227733)
- commit fe2364e

- bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set() (CVE-2024-39487 bsc#1227573)
- commit b775587

- Update
  patches.suse/scsi-scsi_debug-Fix-out-of-bound-read-in-resp_readcap16.patch.
  Fix a build warning about using min() vs min_t().
- commit a4b6164

- xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()
  (CVE-2024-40959 bsc#1227884).
- commit 38ba090

- ocfs2: fix races between hole punching and AIO+DIO (CVE-2024-40943 bsc#1227849).
- commit a8b4b50

- net/sched: act_skbmod: prevent kernel-infoleak (CVE-2024-35893 bsc#1224512)
- commit 3a867bb

- ixgbe: Fix NULL pointer dereference in ixgbe_xdp_setup (CVE-2021-47399 1225328)
- commit f559799

- mlxsw: thermal: Fix out-of-bounds memory accesses (CVE-2021-47441 bsc#1225224)
  Simplified backport. Upstream patch removes code that does not exist in
  SLE12-SP5, the only relevant fix is the bounds checking.
- commit 0b8797d

- cfg80211: call cfg80211_stop_ap when switch from P2P_GO type (CVE-2021-47194 bsc#1222829)
- commit 6cc8bdc

- netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get() (CVE-2024-27020 bsc#1223815)
- commit cfe8cf0

- net: mana: Fix the extra HZ in mana_hwc_send_request (git-fixes).
- net: mana: select PAGE_POOL (git-fixes).
- hv_netvsc: rndis_filter needs to select NLS (git-fixes).
- Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj (git-fixes, bsc#1227924, CVE-2022-48775).
- Tools: hv: kvp: eliminate 'may be used uninitialized' warning (git-fixes).
- tools: hv: fix KVP and VSS daemons exit code (git-fixes).
- commit 51c2361

- netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get() (CVE-2024-27019 bsc#1223813)
- commit 2fcd5af

- wifi: iwlwifi: mvm: check n_ssids before accessing the ssids
  (CVE-2024-40929 bsc#1227774).
- wifi: mac80211: Fix deadlock in
  ieee80211_sta_ps_deliver_wakeup() (CVE-2024-40912 bsc#1227790).
- wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects
  (CVE-2024-40942 bsc#1227770).
- NFC: port100: fix use-after-free in port100_send_complete
  (CVE-2022-48857 bsc#1228005).
- commit 1f497da

- ipv6: fib6_rules: avoid possible NULL dereference in
  fib6_rule_action() (CVE-2024-36902 bsc#1225719).
- commit 4cdf9a2

- USB: core: Make do_proc_control() and do_proc_bulk() killable
  (CVE-2021-47582 bsc#1226559).
- commit 6d322e2

- net: netlink: af_netlink: Prevent empty skb by adding a check
  on len (CVE-2021-47606 bsc#1226555).
- commit 314dfef

- usb: get rid of pointless access_ok() calls (CVE-2021-47582
  bsc#1226559).
- commit 6b48efc

- usb: usbfs: correct kernel-&amp;gt;user page attribute mismatch
  (CVE-2021-47582 bsc#1226559).
- commit d089a07

- USB: usbfs: Always unlink URBs in reverse order (CVE-2021-47582
  bsc#1226559).
- commit 2364ecb

- usb: core: devio.c: Fix assignment of 0/1 to bool variables
  (CVE-2021-47582 bsc#1226559).
- commit 202a764

- usb: usbfs: only account once for mmap()'ed usb memory usage
  (CVE-2021-47582 bsc#1226559).
- commit a282a95

- USB: core: Fix compiler warnings in devio.c (CVE-2021-47582
  bsc#1226559).
- commit d3c8045

- usb: core: Replace hardcoded check with inline function from
  usb.h (CVE-2021-47582 bsc#1226559).
- commit a0c8b54

- usb: usbfs: use irqsave() in USB's complete callback
  (CVE-2021-47582 bsc#1226559).
- commit 89f4a73

- signal: Replace memset(info,...) with clear_siginfo for clarity
  (CVE-2021-47582 bsc#1226559).
- commit 10e5b53

- usbdevfs: get rid of field-by-field copyin (CVE-2021-47582
  bsc#1226559).
- commit 9053160

- scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated
  memory (bsc#1227762 CVE-2024-40901).
- scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()
  (bsc#1225820 CVE-2024-26924).
- scsi: scsi_debug: Fix type in min_t to avoid stack OOB
  (bsc#1226560 CVE-2021-47580).
- commit 4de5c4e

- i40e: Fix VF MAC filter removal (CVE-2024-26830 bsc#1223012).
- commit 55935e5

- i40e: Do not allow untrusted VF to remove administratively
  set MAC (CVE-2024-26830 bsc#1223012).
- nfp: Fix memory leak in nfp_cpp_area_cache_add() (CVE-2021-47516
  bsc#1225427).
- i40e: Fix NULL pointer dereference in i40e_dbg_dump_desc
  (CVE-2021-47501 bsc#1225361).
- commit e2ee4f5

- net: ieee802154: fix null deref in parse dev addr (CVE-2021-47257 bsc#1224896).
- commit 41e01f4

- net/smc: Transitional solution for clcsock race issue (CVE-2022-48751 bsc#1226653). - Refresh patches.suse/net-smc-fix-fallback-failed-while-sendmsg-with-fasto.patch.
- commit 7ad7d3a

- drivers: core: synchronize really_probe() and dev_uevent()
  (CVE-2024-39501 bsc#1227754).
- commit 1b7df5b

- ice: Do not use WQ_MEM_RECLAIM flag for workqueue (CVE-2023-52743 bsc#1225003)
- commit 0b6d94a

- net: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings() (CVE-2021-47542 bsc#1225455)
- commit ce2e7bb

- ipv6: prevent NULL dereference in ip6_output() (CVE-2024-36901 bsc#1225711)
- commit ab46189

- i40e: Do not use WQ_MEM_RECLAIM flag for workqueue (CVE-2024-36004 bsc#1224545)
- commit de141a1

- nbd: null check for nla_nest_start (CVE-2024-27025 bsc#1223778)
- commit b887966

- btrfs: use latest_dev in btrfs_show_devname (CVE-2021-47599 bsc#1226571)
  Simplified backport, keep mutex protection and only remove WARN_ON.
- commit 2ee6fb6

- net: prevent mss overflow in skb_segment() (CVE-2023-52435
  bsc#1220138).
- commit 63a8256

- tipc: Check the bearer type before calling
  tipc_udp_nl_bearer_add() (CVE-2024-26663 bsc#1222326).
- commit 91299f0

- inet_diag: fix kernel-infoleak for UDP sockets
  (CVE-2021-47597 bsc#1226553).
- commit 5ef7515

- ipv6: sr: fix missing sk_buff release in seg6_input_core
  (bsc#1227626 CVE-2024-39490).
- net: openvswitch: fix overwriting ct original tuple for  ICMPv6
  (bsc#1226783 CVE-2024-38558).
- net/smc: fix illegal rmb_desc access in SMC-D connection dump
  (bsc#1220942 CVE-2024-26615).
- commit ee46311

- kabi/severities: Ignore tpm_transmit_cmd and tpm_tis_core_init
  (bsc#1082555).
- commit c8a552a

- Bluetooth: SCO: Fix not validating setsockopt user input
  (bsc#1224576 CVE-2024-35966).
- commit d80abbf

- Update
  patches.suse/SUNRPC-Fix-loop-termination-condition-in-gss_free_in.patch
  (git-fixes CVE-2024-36288 bsc#1226834).
- Update
  patches.suse/arm64-asm-bug-Add-.align-2-to-the-end-of-__BUG_ENTRY.patch
  (git-fixes CVE-2024-39488 bsc#1227618).
- Update
  patches.suse/ax25-fix-use-after-free-bugs-caused-by-ax25_ds_del_t.patch
  (CVE-2024-35887 bzg#1224663 bsc#1224663).
- Update
  patches.suse/net-mlx5e-nullify-cq-dbg-pointer-in-mlx5_debug_cq_re.patch
  (bsc#1225229 CVE-2021-47438 CVE-2021-47197 bsc#1222776).
- Update
  patches.suse/nfs-Handle-error-of-rpc_proc_register-in-nfs_net_ini.patch
  (git-fixes CVE-2024-36939 bsc#1225838).
- Update
  patches.suse/scsi-lpfc-Move-NPIV-s-transport-unregistration-to-after-resource-clean-up.patch
  (bsc#1225898 CVE-2024-36592 CVE-2024-36952).
- Update
  patches.suse/scsi-scsi_debug-Fix-out-of-bound-read-in-resp_readcap16.patch
  (bsc#122286 CVE-2021-47191 bsc#1222866).
- Update
  patches.suse/soc-fsl-qbman-Always-disable-interrupts-when-taking-.patch
  (bsc#1224683 CVE-2024-35819 CVE-2024-35806 bsc#1224699).
- commit 81c691f

- pstore/ram: Fix crash when setting number of cpus to an odd number (bsc#1221618, CVE-2023-52619).
- commit 03ca866

- Fix build warning
  Refresh
  patches.suse/PM-hibernate-x86-Use-crc32-instead-of-md5-for-hibernation-.patch.
- commit 33d6e41

- xhci: Fix incorrect tracking of free space on transfer rings
  (CVE-2024-26659 bsc#1222317).
- commit 985549c

- xhci: process isoc TD properly when there was a transaction
  error mid TD (CVE-2024-26659 bsc#1222317).
- commit 1966e44

- xhci: store TD status in the td struct instead of passing it
  along (CVE-2024-26659 bsc#1222317).
- commit dba92cd

- xhci: Add a separate debug message for split transaction errors
  (CVE-2024-26659 bsc#1222317).
- commit 93897b0

- usb: xhci: Remove ep_trb from finish_td() (CVE-2024-26659
  bsc#1222317).
- commit 75b9c07

- usb: xhci: Remove ep_trb from xhci_cleanup_halted_endpoint()
  (CVE-2024-26659 bsc#1222317).
- Refresh
  patches.suse/xhci-remove-extra-loop-in-interrupt-context.patch.
- commit 93f2e51

- usb: xhci: remove unused variable ep_ring (CVE-2024-26659
  bsc#1222317).
- commit 25ab80d

- xhci: remove extra loop in interrupt context (CVE-2024-26659
  bsc#1222317).
- commit 58c6482

- Bluetooth: Fix memory leak in hci_req_sync_complete()
  (bsc#1224571 CVE-2024-35978).
- commit 0071ef8

- xhci: get isochronous ring directly from endpoint structure
  (CVE-2024-26659 bsc#1222317).
- commit 1c8c540

- crypto: s390/aes - Fix buffer overread in CTR mode
  (CVE-2023-52669 bsc#1224637).
- commit bc65b53

- hwrng: core - Fix page fault dead lock on mmap-ed hwrng
  (CVE-2023-52615 bsc#1221614).
- commit c3d2ac9

- ACPI: CPPC: Fix access width used for PCC registers (bsc#1224557
  CVE-2024-35995).
- commit 33ff733

- ACPI: CPPC: Fix bit_offset shift in MASK_VAL() macro
  (bsc#1224557 CVE-2024-35995).
- commit ae6202b

- SUNRPC: Fix a suspicious RCU usage warning (CVE-2023-52623
  bsc#1222060).
- commit ffa9576

- ACPI: CPPC: Use access_width over bit_width for system memory
  accesses (bsc#1224557 CVE-2024-35995).
- commit ef057c5

- ACPI: CPPC: Drop redundant local variable from cpc_read()
  (bsc#1224557 CVE-2024-35995).
- commit 73812cd

- Update
  patches.suse/scsi-bnx2fc-Remove-spin_lock_bh-while-releasing-resources-after-upload.patch
  (bsc#1225767 CVE-2024-36919).
  fix incorrect bug number
- commit d503d18

- crypto: scomp - fix req-&amp;gt;dst buffer overflow (CVE-2023-52612
  bsc#1221616).
- commit 3b5d943

- xhci: handle isoc Babble and Buffer Overrun events properly
  (CVE-2024-26659 bsc#1222317).
- commit 98fde6e

- net_sched: fix a missing refcnt in tcindex_init() (bsc#1224975).
- commit 45da465

- net_sched: add a temporary refcnt for struct tcindex_data
  (bsc#1224975).
- Refresh
  patches.suse/net-sched-tcindex-update-imperfect-hash-filters-resp.patch.
- commit b3f881b

- net_sched: fix a memory leak in cls_tcindex (bsc#1224975).
- Refresh
  patches.suse/net_sched-fix-an-OOB-access-in-cls_tcindex.patch.
- Refresh
  patches.suse/net_sched-keep-alloc_hash-updated-after-hash-allocat.patch.
- commit 98c1fbb

- net: sched: fix memory leak in tcindex_partial_destroy_work (CVE-2021-47295 bsc#1224975)
- commit 280e278

- net_sched: hold rtnl lock in tcindex_partial_destroy_work() (bsc#1224975)
- commit 6f5da00

- blacklist.conf: convert entry to Alt-commit:
  Refresh   patches.suse/net_sched-fix-a-race-condition-in-tcindex_destroy.patch.
- commit 4a1ea17

- kernel-binary: vdso: Own module_dir
- commit ff69986

- Fix spurious WARNING caused by a qxl driver patch (bsc#1227213,bsc#1227191)
  Refresh patches.suse/drm-qxl-fix-UAF-on-handle-creation.patch
- commit 55a7bf6

Package python-urllib3 was updated:

Package containerd was updated:

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

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

- Update to containerd v1.7.21. Upstream release notes:
  &amp;lt;https://github.com/containerd/containerd/releases/tag/v1.7.21&amp;gt;
  Fixes CVE-2023-47108. bsc#1217070
  Fixes CVE-2023-45142. bsc#1228553
- Rebase patches:
  * 0001-BUILD-SLE12-revert-btrfs-depend-on-kernel-UAPI-inste.patch

- Revert noarch for devel subpackage for SLE 15
  Switching to noarch causes issues on SLES maintenance updates, reverting it
  fixes our image builds

- Update to containerd v1.7.17. Upstream release notes:
  &amp;lt;https://github.com/containerd/containerd/releases/tag/v1.7.17&amp;gt;
- Switch back to using tar_scm service. Aside from obs_scm using more bandwidth
  and storage than a locally-compressed tar.xz, it seems there's some weird
  issue with paths in obscpio that break our SLE-12-only patch.
- Rebase patches:
  * 0001-BUILD-SLE12-revert-btrfs-depend-on-kernel-UAPI-inste.patch
- Update to containerd v1.7.16. Upstream release notes:
  &amp;lt;https://github.com/containerd/containerd/releases/tag/v1.7.16&amp;gt;
  CVE-2023-45288 bsc#1221400

- Use obs_scm service instead of tar_scm
- Removed patch 0002-shim-Create-pid-file-with-0644-permissions.patch
  (merged upstream at
  &amp;lt;https://github.com/containerd/containerd/pull/9571&amp;gt;)
- Update to containerd v1.7.15. Upstream release notes:
  &amp;lt;https://github.com/containerd/containerd/releases/tag/v1.7.15&amp;gt;
- Update to containerd v1.7.14. Upstream release notes:
  &amp;lt;https://github.com/containerd/containerd/releases/tag/v1.7.14&amp;gt;
- Update to containerd v1.7.13. Upstream release notes:
  &amp;lt;https://github.com/containerd/containerd/releases/tag/v1.7.13&amp;gt;
- Update to containerd v1.7.12. Upstream release notes:
  &amp;lt;https://github.com/containerd/containerd/releases/tag/v1.7.12&amp;gt;
- Update to containerd v1.7.11. Upstream release notes:
  &amp;lt;https://github.com/containerd/containerd/releases/tag/v1.7.11&amp;gt;
  GHSA-jq35-85cj-fj4p bsc#1224323

- Use %patch -P N instead of deprecated %patchN.

- Enable manpage generation
- Make devel package noarch
- adjust rpmlint filters

- Add patch for bsc#1217952:
  + 0002-shim-Create-pid-file-with-0644-permissions.patch

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

Package openssl-1_0_0 was updated:

- Pull libopenssl-1_0_0 when updating openssl-1_0_0 with the same  version. [bsc#1228291]

- Security fix: [bsc#1227138, bsc#1227227, CVE-2024-5535]
  * SSL_select_next_proto buffer overread
  * Add openssl-CVE-2024-5535.patch

Package ksh was updated:

- do not use posix_spawn as it lacks proper job handling [bsc#1224057]  new patch: ksh93-no-posix_spawn.dif
- fix segfault in variable substitution [bsc#1129288]
  new patch: ksh93-putval.dif
- fix untrusted environment execution [bsc#1160796] [CVE-2019-14868]
  new patch: ksh93-untrustedenv.dif

Package regionServiceClientConfigGCE was updated:

- Version 4.2.0 (jsc#PCT-361)  + Add IPv6 certs to supprt access of the update infrastructure via
    IPv6 on GCE instances.

Package mozilla-nss was updated:

- Updated nss-fips-approved-crypto-non-ec.patch to enforce  approved curves with the CKK_EC_MONTGOMERY key type (bsc#1224113).

- Require `sed` for mozilla-nss-sysinit, as setup-nsssysinit.sh
  depends on it and will create a broken, empty config, if sed is
  missing (bsc#1227918)

- update to NSS 3.101.2
  * bmo#1905691 - ChaChaXor to return after the function

Package ruby2.1 was updated:

- Add CVE-2024-47220.patch (CVE-2024-47220) Fix HTTP request  smuggling (boo#1230930)

Package suse-build-key was updated:

- extended 2048 bit SUSE SLE 12, 15 GA-SP5 key until 2028. (bsc#1229339)  - gpg-pubkey-39db7c82-5f68629b.asc
  + gpg-pubkey-39db7c82-66c5d91a.asc

Package grub2 was updated:

- Fix btrfs subvolume for platform modules not mounting at runtime when the  default subvolume is the topmost root tree (bsc#1228124)
  * grub2-btrfs-06-subvol-mount.patch
- Rediff
  * 0001-Unify-the-check-to-enable-btrfs-relative-path.patch

- Fix error in grub-install when linux root device is on lvm thin volume
  (bsc#1192622) (bsc#1191974)
- Fix error in grub-install when root is on tmpfs (bsc#1226100)
  * 0001-grub-install-bailout-root-device-probing.patch

Package python36 was updated:

- Remove -IVendor/ from python-config boo#1231795- Fix CVE-2024-11168-validation-IPv6-addrs.patch
- PGO run of build freezes with parallel processing, switch to -j1

- Add CVE-2024-11168-validation-IPv6-addrs.patch
  fixing bsc#1233307 (CVE-2024-11168,
  gh#python/cpython#103848): Improper validation of IPv6 and
  IPvFuture addresses.

- Add CVE-2024-9287-venv_path_unquoted.patch to properly quote
  path names provided when creating a virtual environment
  (bsc#1232241, CVE-2024-9287)

- Drop .pyc files from docdir for reproducible builds
  (bsc#1230906).

- Add CVE-2024-6232-ReDOS-backtrack-tarfile.patch prevent
  ReDos via excessive backtracking while parsing header values
  (bsc#1230227, CVE-2024-6232).

- Add CVE-2024-5642-switch-off-NPN.patch switching off the NPN
  support eliminating bsc#1227233 (CVE-2024-5642).

- Add CVE-2024-6923-email-hdr-inject.patch to prevent email
  header injection due to unquoted newlines (bsc#1228780,
  CVE-2024-6923).
- Add CVE-2024-7592-quad-complex-cookies.patch fixing quadratic
  complexity in parsing cookies with backslashes (bsc#1229596,
  CVE-2024-7592)
- %{profileopt} variable is set according to the variable
  %{do_profiling} (bsc#1227999)

- Remove %suse_update_desktop_file macro as it is not useful any
  more.

- Stop using %%defattr, it seems to be breaking proper executable
  attributes on /usr/bin/ scripts (bsc#1227378).

Package curl was updated:

- Security fix: [bsc#1234068, CVE-2024-11053]  * curl could leak the password used for the first host to the
    followed-to host under certain circumstances.
  * netrc: address several netrc parser flaws
  * Add curl-CVE-2024-11053.patch

- Security fix: [bsc#1232528, CVE-2024-9681]
  * HSTS subdomain overwrites parent cache entry
  * Add curl-CVE-2024-9681.patch

- Make special characters in URL work with aws-sigv4 [bsc#1230516]
  * http_aws_sigv4: canonicalize the query [fc76a24c]
  * test439: verify query canonization for aws-sigv4 [65661016]
  * http_aws_sigv4: skip the op if the query pair is zero bytes [16bdc09e]
  * aws_sigv4: the query canon code miscounted URL encoded input [a1532a33]
  * http_aws_sigv4: canonicalise valueless query params [bbba69da]
  * aws-sigv4: url encode the canonical path [768909d8]
  * Add upstream patches:
  - curl-aws_sigv4-canonicalize-the-query.patch
  - curl-aws_sigv4-verify-query-canonization.patch
  - curl-aws_sigv4-skip-the-op-if-the-query-pair-is-zero-bytes.patch
  - curl-aws_sigv4-the-query-canon-code-miscounted-url-encoded-input.patch
  - curl-aws_sigv4-canonicalise-valueless-query-params.patch
  - curl-aws_sigv4-url-encode-the-canonical-path.patch

- Security fix: [bsc#1230093, CVE-2024-8096]
  * curl: OCSP stapling bypass with GnuTLS
  * Add curl-CVE-2024-8096.patch

- Security fix: [bsc#1228535, CVE-2024-7264]
  * curl: ASN.1 date parser overread
  * Add curl-CVE-2024-7264.patch

Package libpcap was updated:

- Security fix: [bsc#1230034, CVE-2024-8006]  * libpcap: NULL pointer derefence in pcap_findalldevs_ex()
  * Add libpcap-CVE-2024-8006.patch

- Security fix: [bsc#1230020, CVE-2023-7256]
  * libpcap: double free via addrinfo in sock_initaddress()
  * Add libpcap-CVE-2023-7256.patch

Package python3-base was updated:

- Remove -IVendor/ from python-config boo#1231795- Fix CVE-2024-11168-validation-IPv6-addrs.patch
- PGO run of build freezes with parallel processing, switch to -j1

- Add CVE-2024-11168-validation-IPv6-addrs.patch
  fixing bsc#1233307 (CVE-2024-11168,
  gh#python/cpython#103848): Improper validation of IPv6 and
  IPvFuture addresses.

- Add CVE-2024-9287-venv_path_unquoted.patch to properly quote
  path names provided when creating a virtual environment
  (bsc#1232241, CVE-2024-9287)

- Drop .pyc files from docdir for reproducible builds
  (bsc#1230906).

- Add CVE-2024-7592-quad-complex-cookies.patch (bsc#1229596,
  CVE-2024-7592), which fixes quadratic complexity in parsing
  &amp;quot;-quoted cookie values with backslashes by http.cookies.

- Add CVE-2024-6232-ReDOS-backtrack-tarfile.patch prevent
  ReDos via excessive backtracking while parsing header values
  (bsc#1230227, CVE-2024-6232).

- Add bpo27240-rewrite_email_hdr_fold.patch rewriting the email
  header folding algorithm to make the codebase compatible with
  Python 3.6.4+, so we can continue to maintain it.
- And even before that we have to add
  bpo24211-RFC6532-supp-email.patch.
- Also bpo20098-email-mangle_from-policy.patch.
- Add finally, CVE-2024-6923-email-hdr-inject.patch to prevent
  email header injection due to unquoted newlines (bsc#1228780,
  CVE-2024-6923).

- Add CVE-2024-4032-private-IP-addrs.patch to fix bsc#1226448
  (CVE-2024-4032) rearranging definition of private v global IP
  addresses.

- Stop using %%defattr, it seems to be breaking proper executable
  attributes on /usr/bin/ scripts (bsc#1227378).

Package cloud-regionsrv-client was updated:

- Update to 10.3.7 (bsc#1232770)  + Fix the product triplet for LTSS, it is always SLES-LTSS, not
    $BASEPRODUCT-LTSS

- Update to 10.3.6 (jsc#PCT-471, bsc#1230615)
  + Fix sudo setup
    ~ permissions cloudguestregistryauth
    ~ directory ownership /etc/sudoers.d
  + spec file
    ~ Remove traces of registry related entries on SLE 12
  + Forward port
    ~ fix-for-sles12-disable-registry.patch
    ~ fix-for-sles12-no-trans_update.patch
  + Deregister non free extensions at registercloudguest --clean
  + Fix registry cleanup at registercloudguest --clean, don't remove files
  + Prevent duplicate search entries in registry setup
- Update EC2 plugin to 1.0.5
  + Switch to using the region endpoint from IMDS to determine the region
    instead of deriving the data from the availability zone

- Update to 10.3.5
  + Update spec file to build in all code streams,
    SLE 12, SLE 15, ALP, and SLFO and have proper dependencies

- Update to 10.3.4
  + Modify the message when network access over a specific IP version does
    not work. This is an informational message and should not look like
    an error
  + Inform the user that LTSS registration takes a little longer
  + Add fix-for-sles12-no-trans_update.patch
    + SLE 12 family has no products with transactional-update we do not
    need to look for this condition
- From 10.3.3 (bsc#1229472)
  + Handle changes in process structure to properly identify the running
    zypper parent process and only check for 1 PID
- From 10.3.2
  + Remove rgnsrv-clnt-fix-docker-setup.patch included upstream
- From 10.3.1 (jsc#PCT-400)
  + Add support for LTSS registration
  + Add fix-for-sles12-disable-registry.patch
    ~ No container support in SLE 12

- Add rgnsrv-clnt-fix-docker-setup.patch (bsc#1229137)
  + The entry for the update infrastructure registry mirror was written
    incorrectly causing docker daemon startup to fail.

- Update to version 10.3.0 (bsc#1227308, bsc#1222985)
  + Add support for sidecar registry
    Podman and rootless Docker support to set up the necessary
    configuration for the container engines to run as defined
  + Add running command as root through sudoers file

- Update to version 10.2.0 (bsc#1223571, bsc#1224014, bsc#1224016)
  + In addition to logging, write message to stderr when registration fails
  + Detect transactional-update system with read only setup and use
    the transactional-update command to register
  + Handle operation in a different target root directory for credentials
    checking

Package python-setuptools was updated:

- Add patch CVE-2024-6345-code-execution-via-download-funcs.patch:  * Sanitize any VCS URL we download. (CVE-2024-6345, bsc#1228105)

Package python3 was updated:

- Remove -IVendor/ from python-config boo#1231795- Fix CVE-2024-11168-validation-IPv6-addrs.patch
- PGO run of build freezes with parallel processing, switch to -j1

- Add CVE-2024-11168-validation-IPv6-addrs.patch
  fixing bsc#1233307 (CVE-2024-11168,
  gh#python/cpython#103848): Improper validation of IPv6 and
  IPvFuture addresses.

- Add CVE-2024-9287-venv_path_unquoted.patch to properly quote
  path names provided when creating a virtual environment
  (bsc#1232241, CVE-2024-9287)

- Drop .pyc files from docdir for reproducible builds
  (bsc#1230906).

- Add CVE-2024-7592-quad-complex-cookies.patch (bsc#1229596,
  CVE-2024-7592), which fixes quadratic complexity in parsing
  &amp;quot;-quoted cookie values with backslashes by http.cookies.

- Add CVE-2024-6232-ReDOS-backtrack-tarfile.patch prevent
  ReDos via excessive backtracking while parsing header values
  (bsc#1230227, CVE-2024-6232).

- Add bpo27240-rewrite_email_hdr_fold.patch rewriting the email
  header folding algorithm to make the codebase compatible with
  Python 3.6.4+, so we can continue to maintain it.
- And even before that we have to add
  bpo24211-RFC6532-supp-email.patch.
- Also bpo20098-email-mangle_from-policy.patch.
- Add finally, CVE-2024-6923-email-hdr-inject.patch to prevent
  email header injection due to unquoted newlines (bsc#1228780,
  CVE-2024-6923).

- Add CVE-2024-4032-private-IP-addrs.patch to fix bsc#1226448
  (CVE-2024-4032) rearranging definition of private v global IP
  addresses.

- Stop using %%defattr, it seems to be breaking proper executable
  attributes on /usr/bin/ scripts (bsc#1227378).

Package pam was updated:

- Prevent cursor escape from the login prompt [bsc#1194818]  * Added: pam-bsc1194818-cursor-escape.patch

Package shadow was updated:

- bsc#916845 (CVE-2013-4235): Fix TOCTOU race condition  Update shadow-CVE-2013-4235.patch to be more complete

Package python-pyOpenSSL was updated:

- Fix for bsc#1231700:  * 0001-Don-t-use-things-after-they-re-freed.duh-709.patch: Add
    missing patch that introduced X509._from_raw_x509_ptr needed by
    CVE-2018-1000807 fix.
  gh#pyca/pyopenssl@4aa52c33d3ee

Package wicked was updated:

- Update to version 0.6.77  - compat-suse: use iftype in sysctl handling (bsc#1230911, gh#openSUSE/wicked#1043)
  - Always generate the ipv4/ipv6 &amp;lt;enabled&amp;gt;true|false&amp;lt;/enabled&amp;gt; node
  - Inherit all, default and interface sysctl settings also for loopback,
    except for use_tempaddr and accept_dad.
  - Consider only interface specific accept_redirects sysctl settings.
  - Adopt ifsysctl(5) manual page with wicked specific behavior.
  - route: fix family and destination processing (bsc#1231060)
  - man: improve wicked-config(5) file description (gh#openSUSE/wicked#1039)
  - dhcp4: add ignore-rfc3927-1-6 wicked-config(5) option (jsc#PED-10855, gh#openSUSE/wicked#1038)
  - team: set arp link watcher interval default to 1s (gh#openSUSE/wicked#1037)
  - systemd: use `BindsTo=dbus.service` in favor of `Requisite=` (bsc#1229745)
  - compat-suse: fix use of deprecated `INTERFACETYPE=dummy` (boo#1229555)
  - arp: don't set target broadcast hardware address (gh#openSUSE/wicked#1036)
  - dbus: don't memcpy empty/NULL array value (gh#openSUSE/wicked#1035)
  - ethtool: fix leak and free pause data in ethtool_free (gh#openSUSE/wicked#1030)
- Removed patches included in the source archive:
  [- 0001-compat-suse-repair-dummy-interfaces-boo-1229555.patch]

- compat-suse: fix dummy interfaces configuration with
  INTERFACETYPE=dummy (boo#1229555, gh#openSUSE/wicked#1031)
  [+ 0001-compat-suse-repair-dummy-interfaces-boo-1229555.patch]

Package sudo was updated:

- Fix a regression in -P handling cased by fix for CVE-2021-3156  Fix provided by Brahmajit Das [bsc#1234371]
  * sudo-CVE-2021-3156.patch updated

Package google-osconfig-agent was updated:

- Update to version 20240926.03 (bsc#1231775, bsc#1231776)  * Revert &amp;quot;Bump go.opentelemetry.io/otel from 1.24.0 to 1.30.0 (#679)&amp;quot; (#684)
- from version 20240926.02
  * Bump go.opentelemetry.io/otel from 1.24.0 to 1.30.0 (#679)
  * another batch of depencies upgrade (#683)
- from version 20240926.01
  * aggregate dependabot changes to go.mod (#677)
  * Revert back Source package info delivery to control-plane (#673)
- from version 20240926.00
  * Update OWNERS (#676)
- from version 20240924.02
  * Upgrade grpc and it's dependencies to latest version (#672)
- from version 20240924.01
  * Implement keepalive config (#671)
- from version 20240924.00
  * Set new version of gRPC for test (#669)
- from version 20240920.00
  * Revert &amp;quot;bump version of the gRPC&amp;quot; (#667)
- from version 20240919.00
  * bump version of the gRPC (#666)
- from version 20240917.00
  * Merge pull request #665 from GoogleCloudPlatform/revert-664-update_grpc_dependency
  * Revert &amp;quot;Update grpc library and other dependencies. (#664)&amp;quot;
- from version 20240916.00
  * Update grpc library and other dependencies. (#664)
- from version 20240913.00
  * Move packagebuild presubmit to osconfig (#662)
- from version 20240912.00
  * Revert &amp;quot;update osconfig api to v1.13.0 &amp;amp; indirect dependency update&amp;quot; (#659)
- from version 20240822.00
  * Revert &amp;quot;Source package info delivery to control-plane (#639)&amp;quot; (#656)
- from version 20240821.00
  * Fix golang version format to fix builds. (#655)
- from version 20240814.01
  * Use gcsfuse pkg in guest-policies e2e in pkg
    update tests instead of old pkgs (#653)
  * Replace osconfig-agent-test pkg by gcsfuse in ospolicies
    tests and inventory-report tests (#652)
- from version 20240806.00
  * Disable Repository Resource test for SLES-12 (#650)

- Update to version 20240801.00
  * Fix Debian-12 failing test by using gcsfuse pkg
  * Fix fetching gpg key unit tests (#649)
- from version 20240729.00
  * Fix for old state file on Windows (#648)
- from version 20240723.00
  * Add debugging logs for repository resource config (#646)
- from version 20240718.00
  * Fix SLES-12 SP5 RPM package-resource e2e test (#645)
- from version 20240715.01
  * Fix OSPolicies e2e tests for SLES-15 SP5 by removing
    zypper update from VMs startup script (#644)
- from version 20240715.00
  * Fix GuestPolicies e2e tests for SLES-15 SP5 by removing
    zypper update from VMs startup script (#643)
- from version 20240709.01
  * Source package info delivery to control-plane (#639)
- from version 20240709.00
  * Enable gpgcheck flag for RPM e2e tests (#638)
- from version 20240708.00
  * Update osconfig api to v1.13.0
  * Indirect dependency update (#637)
- from version 20240705.01
  * Updating Windows &amp;amp; Linux Chrome packages
    to fix failing e2e tests (#636)
- from version 20240705.00
  * Merge pull request #635 from Gulio/patch-1
  * Update OWNERS
- from version 20240702.02
  * Remove RHEL-7 and CentOS-7 images from e2e tests (#634)

- Update to version 20240702.01
  * Use Debian-11 img in googet pkg build workflow (#632)
- from version 20240702.00
  * Pipeline testing 00 (#631)
- from version 20240701.00
  * update readme file (#628)
- from version 20240625.01
  * Updating yum install to support multi architecture based packages
  * Revert &amp;quot;Adding Architecture to the packages being installed/updated in yum repo&amp;quot;
- from version 20240625.00
  * Update old SLES images urls (#627)
- from version 20240620.00
  * Merge pull request #626 from GoogleCloudPlatform/yum-multiarch-fix
  * Adding Architecture to the packages being installed/updated in yum repo
- from version 20240618.01
  * Extract source_name(source_rpm) for rpm packages (#624)
- from version 20240618.00
  * update README.md file (#625)
- from version 20240615.00
  * Fix(dpkg) return onlt installed items as inventory (#623)
  * Extract source name and version for dpkg packages. (#622)

- Update to version 20240607.00
  * Update e2e tests to use VMM team's GCP project for pkgs testing version (#621)
- from version 20240606.00
  * Disable SUSE tests to run with testing agent repo (#619)
- from version 20240604.00
  * Fix the logic of pick region for Artifact Registry function (#618)
- from version 20240603.00
  * Disable centos-stream-8 tests as it reached EOL in May 31 (#617)
- from version 20240529.00
  * Merge pull request #610 from savijatv/patch-3
  * Update cis-level1-once-a-day-policy.yaml
- from version 20240528.00
  * Merge pull request #616 from MahmoudOuka/allow-windows-e2e-tests-to-\
    install-testing-version-of-agent-from-private-artifact-registry-repos
  * Allow Windows e2e tests to pull osconfig-agent pkg from testing (private)
    repos from Artifact registry
- from version 20240527.01
  * Merge pull request #615 from MahmoudOuka/fix-SUSE-e2e-tests
  * fix SUSE e2e tests
- from version 20240527.00
  * Merge pull request #614 from MahmoudOuka/allow-apt-and-yum-\
    e2e-tests-to-pull-osconfig-agent-pkg-from-testing-repos
  * fix golint comments
  * Allow Apt &amp;amp; Yum e2e tests to pull osconfig-agent pkg from testing repos
- from version 20240524.03
  * Merge pull request #611 from savijatv/patch-ospolicy-samples
  * Update to the CIS OS policy samples
- from version 20240524.00
  * Merge pull request #612 from MahmoudOuka/update-apt-e2e-tests-\
    to-pull-osconfig-agent-pkg-from-new-ar-repos
  * fix golint comment
  * Update Apt e2e tests to pull osconfig-agent pkg from new AR repos instead of rapture
- from version 20240523.02
  * bump golang.org/x/crypto version (#613)
- from version 20240523.00
  * update go-cmp dependency (#604)
- from version 20240522.00
  * rollback masive dependency update (#603)
  * Bump google.golang.org/api from 0.180.0 to 0.181.0 (#596)

- Update to version 20240517.00
  * Bump cloud.google.com/go/auth from 0.4.1 to 0.4.2 (#597)
- from version 20240516.01
  * Bump cloud.google.com/go/logging from 1.9.0 to 1.10.0 (#595)
  * Bump cloud.google.com/go/storage from 1.40.0 to 1.41.0 (#594)
- from version 20240516.00
  * Bump google.golang.org/grpc from 1.63.2 to 1.64.0 (#593)

- Update to version 20240513.02
  * E2e tests: allow passing spesific EL version
    number to InstallOSConfigEL func (#592)
- from version 20240513.01
  * Bump google.golang.org/api from 0.179.0 to 0.180.0 (#591)
- from version 20240513.00
  * E2e tests: Fix EL version detection logic in E2E tests (#590)
  * Bump google.golang.org/api from 0.178.0 to 0.179.0 (#589)
- from version 20240510.02
  * Bump cloud.google.com/go/auth from 0.4.0 to 0.4.1 (#588)
- from version 20240510.01
  * E2e tests: use family url format instead of specific
    version URL for head test images (#587)
- from version 20240510.00
  * Fix for lock location (#586)
- from version 20240509.03
  * Bump cloud.google.com/go from 0.112.2 to 0.113.0 (#584)
- from version 20240509.02
  * Remove dependabot not needed label (#576)
- from version 20240509.01
  * Write inventory to attributes only if enabled (#486)
- from version 20240509.00
  * E2e tests: install gnupg2 and run apt update in VMs startup-scripts (#583)
  * Add a temporary e2e test image for Ubuntu to test
    the latest osconfig-agent stable version (#582)
  * Bump google.golang.org/api from 0.177.0 to 0.178.0 (#578)
  * Bump github.com/googleapis/gax-go/v2 from 2.12.3 to 2.12.4 (#579)
  * Bump cloud.google.com/go/iam from 1.1.7 to 1.1.8 (#577)
  * Bump cloud.google.com/go/auth from 0.3.0 to 0.4.0 (#580)
  * Bump go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc (#581)
  * Bump golang.org/x/net from 0.24.0 to 0.25.0 (#575)
  * Bump cloud.google.com/go/osconfig from 1.12.6 to 1.12.7 (#573)
  * Bump go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp (#574)
  * Bump cloud.google.com/go/longrunning from 0.5.6 to 0.5.7 (#571)
- from version 20240508.08
  * Bump github.com/golang/glog from 1.2.0 to 1.2.1 (#572)
- from version 20240508.07
  * Bump golang.org/x/text from 0.14.0 to 0.15.0 (#565)
- from version 20240508.06
  * Bump golang.org/x/oauth2 from 0.19.0 to 0.20.0 (#566)
  * Bump golang.org/x/sys from 0.19.0 to 0.20.0 (#564)
- from version 20240508.05
  * Bump go.opentelemetry.io/otel/trace from 1.24.0 to 1.26.0 (#563)
- from version 20240508.04
  * Bump google.golang.org/protobuf from 1.34.0 to 1.34.1 (#567)
  * Using the default reviewer set for PR approvals (#570)
- from version 20240508.03
  * Adding advanced CodeQL settings to scan on PRs (#569)
- from version 20240508.02
  * Update Debian-12 package build workflow to use debian-cloud project (#568)
- from version 20240508.01
  * Dependabot dependency updates (#562)
- from version 20240508.00
  * Revert &amp;quot;Initial configuration of the dependabot
    for the direct and indirect dâ¦&amp;quot; (#561)
  * Initial configuration of the dependabot for the
    direct and indirect dependency scanning (#560)
- from version 20240507.00
  * Fix Debian-12 package build workflow typo (#559)
- from version 20240506.00
  * Use signed-by keyring approach for apt repos in Debian 12+ and Ubuntu 24+ (#558)
- from version 20240501.03
  * Logrus dependency update (#557)
- from version 20240501.02
  * Updating dependencies and respective checksums (#556)
- from version 20240501.01
  * Update go.mod (#554)
- from version 20240501.00
  * Bump golang.org/x/net from 0.17.0 to 0.23.0 (#542)
- from version 20240430.01
  * Remove SBOM generation logic from package build workflows (#553)
- from version 20240425.00
  * Fix e2e tests for exec-output size limit (#552)
- from version 20240424.00
  * Disabled some images which are either past EoL or broken (#549)
- from version 20240423.01
  * Copy packagebuild folder from guest-test-infra repo to osconfig repo (#545)
  * OS Config windows state file location changed (#544)
- from version 20240423.00
  * Removed debian-10 from e2e tests (#548)
- from version 20240422.00
  * Merge pull request #541 from GoogleCloudPlatform/michaljankowiak-patch-1
  * Update OWNERS
- from version 20240409.00
  * Bump output size limit to 500KB (#538)

Package expat was updated:

- security update- added patches
  fix CVE-2024-50602 [bsc#1232579], DoS via XML_ResumeParser
  + expat-CVE-2024-50602.patch

- Security fix (bsc#1229932, CVE-2024-45492): detect integer
  overflow in function nextScaffoldPart
  * Added expat-CVE-2024-45492.patch
- Security fix (bsc#1229931, CVE-2024-45491): detect integer
  overflow in dtdCopy
  * Added expat-CVE-2024-45491.patch
- Security fix (bsc#1229930, CVE-2024-45490): reject negative
  len for XML_ParseBuffer
  * Added expat-CVE-2024-45490.patch

- Security fix (bsc#1221563, bsc#1219559, CVE-2023-52425):
  * expat-CVE-2023-52425-1.patch: [PATCH] Grow buffer based on
    current size
  * expat-CVE-2023-52425-2.patch:
  * expat-CVE-2023-52425-backport-parser-changes.patch:
    CVE-2023-52425 Additional parser fixes
  * expat-CVE-2023-52425-fix-tests.patch: CVE-2023-52425 Tests and
    Test suite fixes

Package suseconnect-ng was updated:

- Update version to 1.13:  - Integrating uptime-tracker
  - Honor auto-import-gpg-keys flag on migration (bsc#1231328)
  - Only send labels if targetting SCC
  - Skip the docker auth generation on RMT (bsc#1231185)
  - Add --set-labels to register command to set labels at registration time on SCC
  - Add a new function to display suse-uptime-tracker version
  - Integrate with uptime-tracker ( https://github.com/SUSE/uptime-tracker/ )
  - Add a command to show the info being gathered

- Update version to 1.12:
  - Set the filesystem root on zypper when given (bsc#1230229,bsc#1229014)

- Update version to 1.11
  - Added uname as collector
  - Added SAP workload detection
  - Added detection of container runtimes
  - Multiple fixes on ARM64 detection
  - Use `read_values` for the CPU collector on Z
  - Fixed data collection for ppc64le
  - Grab the home directory from /etc/passwd if needed (bsc#1226128)

- Update version to 1.10.0
  * Build zypper-migration and zypper-packages-search as standalone
    binaries rather then one single binary
  * Add --gpg-auto-import-keys flag before action in zypper command (bsc#1219004)
  * Include /etc/products.d in directories whose content are backed
    up and restored if a zypper-migration rollback happens. (bsc#1219004)
  * Add the ability to upload the system uptime logs, produced by the
    suse-uptime-tracker daemon, to SCC/RMT as part of keepalive report.
    (jsc#PED-7982) (jsc#PED-8018)
  * Add support for third party packages in SUSEConnect
  * Refactor existing system information collection implementation

Package gcc13 was updated:

Package yast2-network was updated:

- Honor the AutoYaST profile allowing to disable the IP check  (bsc#1216859).
- 3.4.12

Package xfsprogs was updated:

- libfrog: fix missing error checking in workqueue code (bsc#1227232)  - add xfsprogs-libfrog-fix-missing-error-checking-in-workqueue-code.patch

- xfs_repair: ignore empty xattr leaf blocks (bsc#1227911)
  - add xfsprogs-xfs_repair-ignore-empty-xattr-leaf-blocks.patch

- mkfs: terminate getsubopt arrays properly (bsc#1228270)
  - add xfsprogs-mkfs-terminate-getsubopt-arrays-properly.patch

- xfs_copy: bail out early when superblock cannot be verified
  (bsc#1227150)
  - fix return value of error code, which is expected to be negative

Package release-notes-sles was updated:

- 12.5.20241206 (tracked in bsc#933411)- Added note about openJDK 11 support status (bsc#1233970)

- 12.5.20241014 (tracked in bsc#933411)
- Added note about openSSH 8.4 (bsc#1222298)
- Added note about unsupported hibernate/suspend on Xen (bsc#1214405)
- Added note about chrony 4.1 (jsc#SLE-22248)
- Added note about adcli --dont-expire-password (jsc#SLE-21223)
- Added note about sudo -U -l restriction (jsc#SLE-22569)
- Added note about nodejs16 addition (jsc#SLE-21234)
- Added note about rsyslog 8.2106 (jsc#SLE-21522)
- Added note about tcl 8.6.12 (jsc#SLE-21015)
- Added note about sudo 1.8.27 update (jsc#SLE-17083)
- Added note about unsupported modules (jsc#PED-8089)

Package vim was updated:

- Fix for bsc#1231373 / CVE-2024-47814.- Fix for bsc#1229238 / CVE-2024-43374.
- update to 9.1.0836
  * 9.1.0836: The vimtutor can be improved
  * 9.1.0835: :setglobal doesn't work properly for 'ffu' and 'tsrfu'
  * 9.1.0834: tests: 2html test fails
  * 9.1.0833: CI: recent ASAN changes do not work for indent tests
  * 9.1.0832: :set doesn't work for 'cot' and 'bkc' after :setlocal
  * runtime(doc): update help-toc description
  * runtime(2html): Make links use color scheme colors in TOhtml
  * 9.1.0831: 'findexpr' can't be used as lambad or Funcref
  * Filelist: include helptoc package
  * runtime(doc): include a TOC Vim9 plugin
  * Filelist: ignore .git-blame-ignore-revs
  * 9.1.0830: using wrong highlight group for spaces for popupmenu
  * runtime(typst): synchronize updates from the upstream typst.vim
  * git: ignore reformatting commit for git-blame (after v9.1.0829)
  * 9.1.0829: Vim source code uses a mix of tabs and spaces
  * 9.1.0828: string_T struct could be used more often
  * 9.1.0827: CI: tests can be improved
  * runtime(doc): remove stray sentence in pi_netrw.txt
  * 9.1.0826: filetype: sway files are not recognized
  * runtime(doc): Include netrw-gp in TOC
  * runtime(doc): mention 'iskeyword' at :h charclass()
  * runtime(doc): update help tags
  * 9.1.0825: compile error for non-diff builds
  * runtime(netrw): fix E874 when browsing remote directory which contains `~` character
  * runtime(doc): update coding style documentation
  * runtime(debversions): Add plucky (25.04) as Ubuntu release name
  * 9.1.0824: too many strlen() calls in register.c
  * 9.1.0823: filetype: Zephyr overlay files not recognized
  * runtime(doc): Clean up minor formatting issues for builtin functions
  * runtime(netrw): make :Launch/Open autoloadable
  * runtime(netrw): fix regression with x mapping on Cygwin
  * runtime(netrw): fix filetype detection for remote files
  * 9.1.0822: topline might be changed in diff mode unexpectedly
  * CI: huge linux builds should also run syntax &amp;amp; indent tests
  * 9.1.0821: 'findexpr' completion doesn't set v:fname to cmdline argument
  * 9.1.0820: tests: Mac OS tests are too flaky
  * runtime(awk): Highlight more awk comments in syntax script
  * runtime(netrw): add missing change for s:redir()
  * 9.1.0819: tests: using findexpr and imported func not tested
  * runtime(netrw): improve netrw's open-handling further
  * runtime(netrw): fix syntax error in netrwPlugin.vim
  * runtime(netrw): simplify gx file handling
  * 9.1.0818: some global functions are only used in single files
  * 9.1.0817: termdebug: cannot evaluate expr in a popup
  * runtime(defaults): Detect putty terminal and switch to dark background
  * 9.1.0816: tests: not clear what tests cause asan failures
  * runtime(doc): Remove some completed items from todo.txt
  * 9.1.0815: &amp;quot;above&amp;quot; virtual text causes wrong 'colorcolumn' position
  * runtime(syntax-tests): tiny vim fails because of line-continuation
  * 9.1.0814: mapset() may remove unrelated mapping
  * 9.1.0813: no error handling with setglobal and number types
  * 9.1.0812: Coverity warns about dereferencing NULL ptr
  * 9.1.0811: :find expansion does not consider 'findexpr'
  * 9.1.0810: cannot easily adjust the |:find| command
  * 9.1.0809: filetype: petalinux config files not recognized
  * 9.1.0808: Terminal scrollback doesn't shrink when decreasing 'termwinscroll'
  * 9.1.0807: tests: having 'nolist' in modelines isn't always desired
  * 9.1.0806: tests: no error check when setting global 'briopt'
  * 9.1.0805: tests: minor issues in gen_opt_test.vim
  * 9.1.0804: tests: no error check when setting global 'cc'
  * 9.1.0803: tests: no error check when setting global 'isk'
  * 9.1.0802: tests: no error check when setting global 'fdm' to empty value
  * 9.1.0801: tests: no error check when setting global 'termwinkey'
  * 9.1.0800: tests: no error check when setting global 'termwinsize'
  * runtime(doc): :ownsyntax also resets 'spelloptions'
  * 9.1.0799: tests: gettwinvar()/gettabwinvar() tests are not comprehensive
  * runtime(doc): Fix wrong Mac default options
  * 9.1.0798: too many strlen() calls in cmdhist.c
  * 9.1.0797: testing of options can be further improved
  * 9.1.0796: filetype: libtool files are not recognized
  * (typst): add folding to typst ftplugin
  * runtime(netrw): deprecate and remove netrwFileHandlers#Invoke()
  * 9.1.0795: filetype: Vivado memory info file are not recognized
  * 9.1.0794: tests: tests may fail on Windows environment
  * runtime(doc): improve the :colorscheme documentation
  * 9.1.0793: xxd: -e does add one extra space
  * 9.1.0792: tests: Test_set_values() is not comprehensive enough
  * runtime(swayconfig): add flag for bindsym/bindcode to syntax script
  * 9.1.0791: tests: errors in gen_opt_test.vim are not shown
  * runtime(compiler): check for compile_commands in build dirs for cppcheck
  * 9.1.0790: Amiga: AmigaOS4 build should use default runtime (newlib)
  * runtime(help): Update help syntax
  * runtime(help): fix end of sentence highlight in code examples
  * runtime(jinja): Support jinja syntax as secondary filetype
  * 9.1.0789: tests: ':resize + 5' has invalid space after '+'
  * 9.1.0788: &amp;lt;CSI&amp;gt;27;&amp;lt;mod&amp;gt;u is not decoded to literal Escape in kitty/foot
  * 9.1.0787: cursor position changed when using hidden terminal
  * 9.1.0786: tests: quickfix update test does not test location list
  * runtime(doc): add some docs for file-watcher programs
  * CI: uploading failed screendumps still fails on Cirrus CI
  * 9.1.0785: cannot preserve error position when setting quickfix list
  * 9.1.0784: there are several problems with python 3.13
  * 9.1.0783: 'spell' option setting has problems
  * 9.1.0782: tests: using wrong neomuttlog file name
  * runtime(doc): add preview flag to statusline example
  * 9.1.0781: tests: test_filetype fails
  * 9.1.0780: MS-Windows: incorrect Win32 error checking
  * 9.1.0779: filetype: neomuttlog files are not recognized
  * 9.1.0778: filetype: lf config files are not recognized
  * runtime(comment): fix commment toggle with mixed tabs &amp;amp; spaces
  * runtime(misc): Use consistent &amp;quot;Vim script&amp;quot; spelling
  * runtime(gleam): add ftplugin for gleam files
  * runtime(doc): link help-writing from write-local-help
  * 9.1.0777: filetype: Some upstream php files are not recognized
  * runtime(java): Define javaBlockStart and javaBlockOtherStart hl groups
  * runtime(doc): mention conversion rules for remote_expr()
  * runtime(tutor): Fix missing :s command in spanish translation section 4.4
  * 9.1.0776: test_strftime may fail because of missing TZ data
  * translation(am): Add Armenian language translation
  * 9.1.0775: tests: not enough tests for setting options
  * 9.1.0774: &amp;quot;shellcmdline&amp;quot; doesn't work with getcompletion()
  * 9.1.0773: filetype: some Apache files are not recognized
  * 9.1.0772: some missing changes from v9.1.0771
  * 9.1.0771: completion attribute hl_group is confusing
  * 9.1.0770: current command line completion is a bit limited
  * 9.1.0769: filetype: MLIR files are not recognized
  * 9.1.0768: MS-Windows: incorrect cursor position when restoring screen
  * runtime(nasm): Update nasm syntax script
  * 9.1.0767: A condition is always true in ex_getln.c
  * runtime(skill): Update syntax file to fix string escapes
  * runtime(help): highlight CTRL-&amp;lt;Key&amp;gt; correctly
  * runtime(doc): add missing usr_52 entry to toc
  * 9.1.0766: too many strlen() calls in ex_getln.c
  * runtime(doc): correct `vi` registers 1-9 documentation error
  * 9.1.0765: No test for patches 6.2.418 and 7.3.489
  * runtime(spec): set comments and commentstring options
  * NSIS: Include libgcc_s_sjlj-1.dll again
  * runtime(doc): clarify the effect of 'startofline' option
  * 9.1.0764: [security]: use-after-free when closing a buffer
  * runtime(vim): Update base-syntax file, improve class, enum and interface highlighting
  * 9.1.0763: tests: cannot run single syntax tests
  * 9.1.0762: 'cedit', 'termwinkey' and 'wildchar' may not be parsed correctly
  * 9.1.0761: :cd completion fails on Windows with backslash in path
  * 9.1.0760: tests: no error reported, if gen_opt_test.vim fails
  * 9.1.0759: screenpos() may return invalid position
  * runtime(misc): unset compiler in various ftplugins
  * runtime(doc): update formatting and syntax
  * runtime(compiler): add cppcheck linter compiler plugin
  * runtime(doc): Fix style in documents
  * runtime(doc): Fix to two-space convention in user manual
  * runtime(comment): consider &amp;amp;tabstop in lines after whitespace indent
  * 9.1.0758: it's possible to set an invalid key to 'wildcharm'
  * runtime(java): Manage circularity for every :syn-included syntax file
  * 9.1.0757: tests: messages files contains ANSI escape sequences
  * 9.1.0756: missing change from patch v9.1.0754
  * 9.1.0755: quickfix list does not handle hardlinks well
  * runtime(doc): 'filetype', 'syntax' and 'keymap' only allow alphanumeric + some characters
  * runtime(systemd): small fixes to &amp;amp;keywordprg in ftplugin
  * CI: macos-12 runner is being sunset, switch to 13
  * 9.1.0754: fixed order of items in insert-mode completion menu
  * runtime(comment): commenting might be off by one column
  * 9.1.0753: Wrong display when typing in diff mode with 'smoothscroll'
  * 9.1.0752: can set 'cedit' to an invalid value
  * runtime(doc): add `usr` tag to usr_toc.txt
  * 9.1.0751: Error callback for term_start() not used
  * 9.1.0750: there are some Win9x legacy references
  * runtime(java): Recognise the CommonMark form (///) of Javadoc comments
  * 9.1.0749: filetype: http files not recognized
  * runtime(comment): fix syntax error
  * CI: uploading failed screendump tests does not work Cirrus
  * 9.1.0748: :keep* commmands are sometimes misidentified as :k
  * runtime(indent): allow matching negative numbers for gnu indent config file
  * runtime(comment): add gC mapping to (un)comment rest of line
  * 9.1.0747: various typos in repo found
  * 9.1.0746: tests: Test_halfpage_longline() fails on large terminals
  * runtime(doc): reformat gnat example
  * runtime(doc): reformat ada_standard_types section
  * 9.1.0745: filetype: bun and deno history files not recognized
  * runtime(glvs): Correct the tag name of glvs-autoinstal
  * runtime(doc): include short form for :earlier/:later
  * runtime(doc): remove completed TODO
  * 9.1.0744: filetype: notmuch configs are not recognised
  * 9.1.0743: diff mode does not handle overlapping diffs correctly
  * runtime(glvs): fix a few issues
  * runtime(doc): Fix typo in :help :command-modifiers
  * 9.1.0742: getcmdprompt() implementation can be improved
  * runtime(docs): update `:set?` command behavior table
  * runtime(doc): update vim90 to vim91 in docs
  * runtime(doc): fix typo in :h dos-colors
  * 9.1.0741: No way to get prompt for input()/confirm()
  * runtime(doc): fix typo in version9.txt nrformat -&amp;gt; nrformats
  * runtime(rmd,rrst): 'fex' option not properly restored
  * runtime(netrw): remove extraneous closing bracket
  * 9.1.0740: incorrect internal diff with empty file
  * 9.1.0739: [security]: use-after-free in ex_getln.c
  * runtime(filetype): tests: Test_filetype_detection() fails
  * runtime(dist): do not output a message if executable is not found
  * 9.1.0738: filetype: rapid files are not recognized
  * runtime(modconf): remove erroneous :endif in ftplugin
  * runtime(lyrics): support multiple timestamps in syntax script
  * runtime(java): Optionally recognise _module_ import declarations
  * runtime(vim): Update base-syntax, improve folding function matches
  * CI: upload failed screendump tests also for Cirrus
  * 9.1.0737: tests: screendump tests may require a bit more time
  * runtime(misc): simplify keywordprg in various ftplugins
  * runtime(java): Optionally recognise all primitive constants in _switch-case_ labels
  * runtime(zsh,sh): set and unset compiler in ftplugin
  * runtime(netrw): using inefficient highlight pattern for 'mf'
  * 9.1.0736: Unicode tables are outdated
  * 9.1.0735: filetype: salt files are not recognized
  * 9.1.0734: filetype: jinja files are not recognized
  * runtime(zathurarc): add double-click-follow to syntax script
  * translation(ru): Updated messages translation
  * translation(it): updated xxd man page
  * translation(ru): updated xxd man page
  * 9.1.0733: keyword completion does not work with fuzzy
  * 9.1.0732: xxd: cannot use -b and -i together
  * runtime(java): Highlight javaConceptKind modifiers with StorageClass
  * runtime(doc): reword and reformat how to use defaults.vim
  * 9.1.0731: inconsistent case sensitive extension matching
  * runtime(vim): Update base-syntax, match Vim9 bool/null literal args to :if/:while/:return
  * runtime(netrw): delete confirmation not strict enough
  * 9.1.0730: Crash with cursor-screenline and narrow window
  * 9.1.0729: Wrong cursor-screenline when resizing window
  * 9.1.0728: [security]: heap-use-after-free in garbage collection with location list user data
  * runtime(doc): clarify the effect of the timeout for search()-functions
  * runtime(idlang): update syntax script
  * runtime(spec): Recognize epoch when making spec changelog in ftplugin
  * runtime(spec): add file triggers to syntax script
  * 9.1.0727: too many strlen() calls in option.c
  * runtime(make): add compiler/make.vim to reset compiler plugin settings
  * runtime(java): Recognise all available standard doclet tags
  * 9.1.0726: not using correct python3 API with dynamic linking
  * runtime(dosini): Update syntax script, spellcheck comments only
  * runtime(doc): Revert outdated comment in completeopt's fuzzy documentation
  * 9.1.0725: filetype: swiftinterface files are not recognized
  * runtime(pandoc): Update compiler plugin to use actual 'spelllang'
  * runtime(groff): Add compiler plugin for groff
  * 9.1.0724: if_python: link error with python 3.13 and stable ABI
  * 9.1.0723: if_python: dynamic linking fails with python3 &amp;gt;= 3.13
  * 9.1.0722: crash with large id in text_prop interface
  * 9.1.0721: tests: test_mksession does not consider XDG_CONFIG_HOME
  * runtime(glvs): update GetLatestVimScripts plugin
  * runtime(doc): Fix typo in :help :hide text
  * runtime(doc): buffers can be re-used
  * 9.1.0720: Wrong breakindentopt=list:-1 with multibyte or TABs
  * 9.1.0719: Resetting cell widths can make 'listchars' or 'fillchars' invalid
  * runtime(doc): Update version9.txt and mention $MYVIMDIR
- Update to 9.1.0718:
  * v9.1.0718: hard to know the users personal Vim Runtime Directory
  * v9.1.0717: Unnecessary nextcmd NULL checks in parse_command_modifiers()
    Maintainers: fix typo in author name
  * v9.1.0716: resetting setcellwidth( doesn't update the screen
    runtime(hcl,terraform): Add runtime files for HCL and Terraform
    runtime(tmux): Update syntax script
  * v9.1.0715: Not correctly parsing color names (after v9.1.0709)
  * v9.1.0714: GuiEnter_Turkish test may fail
  * v9.1.0713: Newline causes E749 in Ex mode
  * v9.1.0712: missing dependency of Test_gettext_makefile
  * v9.1.0711: test_xxd may file when using different xxd
  * v9.1.0710: popup window may hide part of Command line
    runtime(vim): Update syntax, improve user-command matching
  * v9.1.0709: GUIEnter event not found in Turkish locale
    runtime(sudoers): improve recognized Runas_Spec and Tag_Spec items
  * v9.1.0708: Recursive window update does not account for reset skipcol
    runtime(nu): include filetype plugin
  * v9.1.0707: invalid cursor position may cause a crash
  * v9.1.0706: test_gettext fails when using shadow dir
    CI: Install locales-all package
  * v9.1.0705: Sorting of fuzzy filename completion is not stable
    translation(pt): update Portuguese/Brazilian menu translation
    runtime(vim): Update base-syntax, match bracket mark ranges
    runtime(doc): Update :help :command-complete list
  * v9.1.0704: inserting with a count is inefficient
    runtime(doc): use mkdir -p to save a command
  * v9.1.0703: crash with 2byte encoding and glob2regpat()
    runtime(hollywood): update syn highlight for If-Then statements
    and For-In-Loops
  * v9.1.0702: Patch 9.1.0700 broke CI
  * v9.1.0701: crash with NFA regex engine when searching for
    composing chars
  * v9.1.0700: crash with 2byte encoding and glob2regpat()
  * v9.1.0699: &amp;quot;dvgo&amp;quot; is not always an inclusive motion
    runtime(java): Provide support for syntax preview features
  * v9.1.0698: &amp;quot;Untitled&amp;quot; file not removed when running Test_crash1_3
    alone
  * v9.1.0697: heap-buffer-overflow in ins_typebuf
  * v9.1.0696: installing runtime files fails when using SHADOWDIR
    runtime(doc): fix typo
  * v9.1.0695: test_crash leaves Untitled file around
    translation(br): Update Brazilian translation
    translation(pt): Update menu_pt_br
  * v9.1.0694: matchparen is slow on a long line
  * v9.1.0693: Configure doesn't show result when not using python3
    stable abi
  * v9.1.0692: Wrong patlen value in ex_substitute()
  * v9.1.0691: stable-abi may cause segfault on Python 3.11
    runtime(vim): Update base-syntax, match :loadkeymap after colon and bar
    runtime(mane): Improve &amp;lt;Plug&amp;gt;ManBS mapping
  * v9.1.0690: cannot set special highlight kind in popupmenu
    translation(pt): Revert and fix wrong Portuguese menu translation
    files
    translation(pt): revert Portuguese menu translation
    translation(br): Update Brazilian translations
    runtime(vim): Update base-syntax, improve :let-heredoc highlighting
  * v9.1.0689: buffer-overflow in do_search( with 'rightleft'
    runtime(vim): Improve heredoc handling for all embedded scripts
  * v9.1.0688: dereferences NULL pointer in check_type_is_value()
  * v9.1.0687: Makefile may not install desktop files
    runtime(man): Fix &amp;lt;Plug&amp;gt;ManBS
    runtime(java): Make the bundled &amp;amp;foldtext function optional
    runtime(netrw): Change line on `mx` if command output exists
    runtime(netrw): Fix `mf`-selected entry highlighting
    runtime(htmlangular): add html syntax highlighting
    translation(it): Fix filemode of Italian manpages
    runtime(doc): Update outdated man.vim plugin information
    runtime(zip): simplify condition to detect MS-Windows
  * v9.1.0686: zip-plugin has problems with special characters
    runtime(pandoc): escape quotes in &amp;amp;errorformat for pandoc
    translation(it): updated Italian manpage
  * v9.1.0685: too many strlen( calls in usercmd.c
    runtime(doc): fix grammar in :h :keeppatterns
    runtime(pandoc): refine pandoc compiler settings
  * v9.1.0684: completion is inserted on Enter with &amp;quot;noselect&amp;quot;
    translation(ru): update man pages
  * v9.1.0683: mode( returns wrong value with &amp;lt;Cmd&amp;gt; mapping
    runtime(doc): remove trailing whitespace in cmdline.txt
  * v9.1.0682: Segfault with uninitialized funcref
  * v9.1.0681: Analyzing failed screendumps is hard
    runtime(doc): more clarification for the :keeppatterns needed
  * v9.1.0680: VMS does not have defined uintptr_t
    runtime(doc): improve typedchar documentation for KeyInputPre autocmd
    runtime(dist): verify that executable is in $PATH
    translation(it): update Italian manpages
    runtime(doc): clarify the effect of :keeppatterns after * v9.1.0677
    runtime(doc): update Makefile and make it portable between GNU and BSD
  * v9.1.0679: Rename from w_closing to w_locked is incomplete
    runtime(colors): update colorschemes
    runtime(vim): Update base-syntax, improve :let-heredoc highlighting
    runtime(doc): Updating the examples in the xxd manpage
    translation(ru): Updated uganda.rux
    runtime(yaml): do not re-indent when commenting out lines
  * v9.1.0678: use-after-free in alist_add()
  * v9.1.0677 :keepp does not retain the substitute pattern
    translation(ja): Update Japanese translations to latest release
    runtime(netrw): Drop committed trace lines
    runtime(netrw): Error popup not always used
    runtime(netrw): ErrorMsg( may throw E121
    runtime(tutor): update Makefile and make it portable between GNU and BSD
    translation: improve the po/cleanup.vim script
    runtime(lang): update Makefile and make it portable between GNU and BSD
  * v9.1.0676: style issues with man pages
  * v9.1.0675: Patch v9.1.0674 causes problems
    runtime(dosbatch): Show %%i as an argument in syntax file
    runtime(dosbatch): Add syn-sync to syntax file
    runtime(sql, mysql): fix E169: Command too recursive with
    sql_type_default = &amp;quot;mysql&amp;quot;
  * v9.1.0674: compiling abstract method fails because of missing return
    runtime(javascript): fix a few issues with syntax higlighting
    runtime(mediawiki): fix typo in doc, test for b:did_ftplugin var
    runtime(termdebug): Fix wrong test for balloon feature
    runtime(doc): Remove mentioning of the voting feature
    runtime(doc): add help tags for json + markdown global variables
  * v9.1.0673: too recursive func calls when calling super-class method
    runtime(syntax-tests): Facilitate the viewing of rendered screendumps
    runtime(doc): fix a few style issues
  * v9.1.0672: marker folds may get corrupted on undo
  * v9.1.0671 Problem:  crash with WinNewPre autocommand
  * v9.1.0670: po file encoding fails on *BSD during make
    translation(it): Update Italian translation
    translation: Stop using msgconv
  * v9.1.0669: stable python ABI not used by default
    Update .gitignore and .hgignore files
  * v9.1.0668: build-error with python3.12 and stable ABI
    translations: Update generated po files
  * v9.1.0667: Some other options reset curswant unnecessarily when set
  * v9.1.0666: assert_equal( doesn't show multibyte string correctly
    runtime(doc): clarify directory of Vim's executable vs CWD
  * v9.1.0665 :for loop
    runtime(proto): Add indent script for protobuf filetype
  * v9.1.0664: console vim did not switch back to main screen on exit
    runtime(zip): zip plugin does not work with Vim 9.0
  * v9.1.0663: zip test still resets 'shellslash' option
    runtime(zip): use defer to restore old settings
    runtime(zip): add a generic Message function
    runtime(zip): increment base version of zip plugin
    runtime(zip): raise minimum Vim version to * v9.0
    runtime(zip): refactor save and restore of options
    runtime(zip): remove test for fnameescape
    runtime(zip): use :echomsg instead of :echo
    runtime(zip): clean up and remove comments
  * v9.1.0662: filecopy( may return wrong value when readlink( fails
  * v9.1.0661: the zip plugin is not tested.
    runtime(zip): Fix for FreeBSD's unzip command
    runtime(doc): capitalize correctly
  * v9.1.0660: Shift-Insert does work on old conhost
    translation(it): update Italian manpage
    runtime(lua): add/subtract a 'shiftwidth' after '('/')' in indentexpr
    runtime(zip): escape '[' on Unix as well
  * v9.1.0659: MSVC Makefile is a bit hard to read
    runtime(doc): fix typo in syntax.txt
    runtime(doc): -x is only available when compiled with crypt feature
  * v9.1.0658: Coverity warns about dereferencing NULL pointer.
    runtime(colors): update Todo highlight in habamax colorscheme
  * v9.1.0657: MSVC build time can be optimized
  * v9.1.0656: MSVC Makefile CPU handling can be improved
  * v9.1.0655: goaccess config file not recognized
    CI: update clang compiler to version 20
    runtime(netrw): honor `g:netrw_alt{o,v}` for `:{S,H,V}explore`
  * v9.1.0654: completion does not respect completeslash with fuzzy
  * v9.1.0653: Patch v9.1.0648 not completely right
  * v9.1.0652: too many strlen( calls in syntax.c
  * v9.1.0651 :append
  * v9.1.0650: Coverity warning in cstrncmp()
  * v9.1.0649: Wrong comment for &amp;quot;len&amp;quot; argument of call_simple_func()
  * v9.1.0648: [security] double-free in dialog_changed()
  * v9.1.0647: [security] use-after-free in tagstack_clear_entry
    runtime(doc): re-format tag example lines, mention ctags --list-kinds
  * v9.1.0646: imported function may not be found
    runtime(java): Document &amp;quot;g:java_space_errors&amp;quot; and &amp;quot;g:java_comment_strings&amp;quot;
    runtime(java): Cluster optional group definitions and their group links
    runtime(java): Tidy up the syntax file
    runtime(java): Tidy up the documentation for &amp;quot;ft-java-syntax&amp;quot;
    runtime(colors): update habamax scheme - tweak diff/search/todo colors
    runtime(nohlsearch): add missing loaded_hlsearch guard
    runtime(kivy): Updated maintainer info for syntax script
    Maintainers: Add maintainer for ondir ftplugin + syntax files
    runtime(netrw): removing trailing slash when copying files in same
    directory
  * v9.1.0645: wrong match when searching multi-byte char case-insensitive
    runtime(html): update syntax script to sync by 250 minlines by default
  * v9.1.0644: Unnecessary STRLEN( when applying mapping
    runtime(zip): Opening a remote zipfile don't work
    runtime(cuda): source c and cpp ftplugins
  * v9.1.0643: cursor may end up on invalid position
  * v9.1.0642: Check that mapping rhs starts with lhs fails if not
    simplified
  * v9.1.0641: OLE enabled in console version
    runtime(thrift): add ftplugin, indent and syntax scripts
  * v9.1.0640: Makefile can be improved
  * v9.1.0639: channel timeout may wrap around
  * v9.1.0638: E1510 may happen when formatting a message for smsg()
  * v9.1.0637: Style issues in MSVC Makefile
- Update apparmor.vim to latest version (from AppArmor 4.0.2)
  - add support for &amp;quot;all&amp;quot; and &amp;quot;userns&amp;quot; rules, and new profile flags
- Update to 9.1.0636:
  * 9.1.0636: filetype: ziggy files are not recognized
  * 9.1.0635: filetype: SuperHTML template files not recognized
  * 9.1.0634: Ctrl-P not working by default
  * 9.1.0633: Compilation warnings with `-Wunused-parameter`
  * 9.1.0632: MS-Windows: Compiler Warnings
  Add support for Files-Included in syntax script
  tweak documentation style a bit
  * 9.1.0631: wrong completion list displayed with non-existing dir + fuzzy completion
  * 9.1.0630: MS-Windows: build fails with VIMDLL and mzscheme
  * 9.1.0629: Rename of pum hl_group is incomplete
  * 9.1.0628: MinGW: coverage files are not cleaned up
  * 9.1.0627: MinGW: build-error when COVERAGE is enabled
  * 9.1.0626: Vim9: need more tests with null objects
  include initial filetype plugin
  * 9.1.0625: tests: test output all translated messages for all translations
  * 9.1.0624: ex command modifiers not found
  * 9.1.0623: Mingw: errors when trying to delete non-existing files
  * 9.1.0622: MS-Windows: mingw-build can be optimized
  * 9.1.0621: MS-Windows: startup code can be improved
  * 9.1.0620: Vim9: segfauls with null objects
  * 9.1.0619: tests: test_popup fails
  * 9.1.0618: cannot mark deprecated attributes in completion menu
  * 9.1.0617: Cursor moves beyond first line of folded end of buffer
  * 9.1.0616: filetype: Make syntax highlighting off for MS Makefiles
  * 9.1.0615: Unnecessary STRLEN() in make_percent_swname()
  Add single-line comment syntax
  Add syntax test for comments
  Update maintainer info
  * 9.1.0614: tests: screendump tests fail due to recent syntax changes
  * 9.1.0613: tests: termdebug test may fail and leave file around
  Update base-syntax, improve :set highlighting
  Optionally highlight the :: token for method references
  * 9.1.0612: filetype: deno.lock file not recognized
  Use delete() for deleting directory
  escape filename before trying to delete it
  * 9.1.0611: ambiguous mappings not correctly resolved with modifyOtherKeys
  correctly extract file from zip browser
  * 9.1.0610: filetype: OpenGL Shading Language files are not detected
  Fix endless recursion in netrw#Explore()
  * 9.1.0609: outdated comments in Makefile
  update syntax script
  Fix flow mapping key detection
  Remove orphaned YAML syntax dump files
  * 9.1.0608: Coverity warns about a few potential issues
  Update syntax script and remove syn sync
  * 9.1.0607: termdebug: uses inconsistent style
  * 9.1.0606: tests: generated files may cause failure in test_codestyle
  * 9.1.0605: internal error with fuzzy completion
  * 9.1.0604: popup_filter during Press Enter prompt seems to hang
  translation: Update Serbian messages translation
  * 9.1.0603: filetype: use correct extension for Dracula
  * 9.1.0602: filetype: Prolog detection can be improved
  fix more inconsistencies in assert function docs
  * 9.1.0601: Wrong cursor position with 'breakindent' when wide char doesn't fit
  Update base-syntax, improve :map highlighting
  * 9.1.0600: Unused function and unused error constants
  * 9.1.0599: Termdebug: still get E1023 when specifying arguments
  correct wrong comment options
  fix typo &amp;quot;a xterm&amp;quot; -&amp;gt; &amp;quot;an xterm&amp;quot;
  * 9.1.0598: fuzzy completion does not work with default completion
  * 9.1.0597: KeyInputPre cannot get the (unmapped typed) key
  * 9.1.0596: filetype: devscripts config files are not recognized
  gdb file/folder check is now performed only in CWD.
  quote filename arguments using double quotes
  update syntax to SDC-standard 2.1
  minor updates.
  Cleanup :match and :loadkeymap syntax test files
  Update base-syntax, match types in Vim9 variable declarations
  * 9.1.0595: make errors out with the po Makefile
  * 9.1.0594: Unnecessary redraw when setting 'winfixbuf'
  using wrong highlight for UTF-8
  include simple syntax plugin
  * 9.1.0593: filetype: Asymptote files are not recognized
  add recommended indent options to ftplugin
  add recommended indent options to ftplugin
  add recommended indent options to ftplugin
  * 9.1.0592: filetype: Mediawiki files are not recognized
  * 9.1.0591: filetype: *.wl files are not recognized
  * 9.1.0590: Vim9: crash when accessing getregionpos() return value
  'cpoptions': Include &amp;quot;z&amp;quot; in the documented default
  * 9.1.0589: vi: d{motion} and cw work differently than expected
  update included colorschemes
  grammar fixes in options.txt
- Add &amp;quot;Keywords&amp;quot; to gvim.desktop to make searching for gvim easier
- Removed patches, as they're no longer required (refreshing them
  deleted their contents):
  * vim-7.3-help_tags.patch
  * vim-7.4-highlight_fstab.patch
- Reorganise all applied patches in the spec file.
- Update to 9.1.0588:
  * 9.1.0588: The maze program no longer compiles on newer clang
    runtime(typst): Add typst runtime files
  * 9.1.0587: tests: Test_gui_lowlevel_keyevent is still flaky
  * 9.1.0586: ocaml runtime files are outdated
    runtime(termdebug): fix a few issues
  * 9.1.0585: tests: test_cpoptions leaves swapfiles around
  * 9.1.0584: Warning about redeclaring f_id() non-static
    runtime(doc): Add hint how to load termdebug from vimrc
    runtime(doc): document global insert behavior
  * 9.1.0583: filetype: *.pdf_tex files are not recognized
  * 9.1.0582: Printed line doesn't overwrite colon when pressing Enter in Ex mode
  * 9.1.0581: Various lines are indented inconsistently
  * 9.1.0580: :lmap mapping for keypad key not applied when typed in Select mode
  * 9.1.0579: Ex command is still executed after giving E1247
  * 9.1.0578: no tests for :Tohtml
  * 9.1.0577: Unnecessary checks for v:sizeoflong in test_put.vim
  * 9.1.0576: tests: still an issue with test_gettext_make
  * 9.1.0575: Wrong comments in alt_tabpage()
  * 9.1.0574: ex: wrong handling of commands after bar
    runtime(doc): add a note for netrw bug reports
  * 9.1.0573: ex: no implicit print for single addresses
    runtime(vim): make &amp;amp;indentexpr available from the outside
  * 9.1.0572: cannot specify tab page closing behaviour
    runtime(doc): remove obsolete Ex insert behavior
  * 9.1.0571: tests: Test_gui_lowlevel_keyevent is flaky
    runtime(logindefs): update syntax with new keywords
  * 9.1.0570: tests: test_gettext_make can be improved
    runtime(filetype): Fix Prolog file detection regex
  * 9.1.0569: fnamemodify() treats &amp;quot;..&amp;quot; and &amp;quot;../&amp;quot; differently
    runtime(mojo): include mojo ftplugin and indent script
  * 9.1.0568: Cannot expand paths from 'cdpath' setting
  * 9.1.0567: Cannot use relative paths as findfile() stop directories
  * 9.1.0566: Stop dir in findfile() doesn't work properly w/o trailing slash
  * 9.1.0565: Stop directory doesn't work properly in 'tags'
  * 9.1.0564: id() can be faster
  * 9.1.0563: Cannot process any Key event
  * 9.1.0562: tests: inconsistency in test_findfile.vim
    runtime(fstab): Add missing keywords to fstab syntax
  * 9.1.0561: netbeans: variable used un-initialized (Coverity)
  * 9.1.0560: bindtextdomain() does not indicate an error
  * 9.1.0559: translation of vim scripts can be improved
  * 9.1.0558: filetype: prolog detection can be improved
  * 9.1.0557: moving in the buffer list doesn't work as documented
    runtime(doc): fix inconsistencies in :h file-searching
  * 9.1.0556: :bwipe doesn't remove file from jumplist of other tabpages
    runtime(htmlangular): correct comment
  * 9.1.0555: filetype: angular ft detection is still problematic
  * 9.1.0554: :bw leaves jumplist and tagstack data around
  * 9.1.0553: filetype: *.mcmeta files are not recognized
  * 9.1.0552: No test for antlr4 filetype
  * 9.1.0551: filetype: htmlangular files are not properly detected
  * 9.1.0550: filetype: antlr4 files are not recognized
  * 9.1.0549: fuzzycollect regex based completion not working as expected
    runtime(doc): autocmd_add() accepts a list not a dict
  * 9.1.0548: it's not possible to get a unique id for some vars
    runtime(tmux): Update syntax script
  * 9.1.0547: No way to get the arity of a Vim function
  * 9.1.0546: vim-tiny fails on CTRL-X/CTRL-A
    runtime(hlsplaylist): include hlsplaylist ftplugin file
    runtime(doc): fix typo in :h ft-csv-syntax
    runtime(doc): Correct shell command to get $VIMRUNTIME into
    shell
  * 9.1.0545: MSVC conversion warning
  * 9.1.0544: filetype: ldapconf files are not recognized
    runtime(cmakecache): include cmakecache ftplugin file
    runtime(lex): include lex ftplugin file
    runtime(yacc): include yacc ftplugin file
    runtime(squirrel): include squirrel ftplugin file
    runtime(objcpp): include objcpp ftplugin file
    runtime(tf): include tf ftplugin file
    runtime(mysql): include mysql ftplugin file
    runtime(javacc): include javacc ftplugin file
    runtime(cabal): include cabal ftplugin file
    runtime(cuda): include CUDA ftplugin file
    runtime(editorconfig): include editorconfig ftplugin file
    runtime(kivy): update kivy syntax, include ftplugin
    runtime(syntax-tests): Stop generating redundant &amp;quot;*_* 99.dump&amp;quot;
    files
  * 9.1.0543: Behavior of CursorMovedC is strange
    runtime(vim): Update base-syntax, improve :match command
    highlighting
  * 9.1.0542: Vim9: confusing string() output for object functions
  * 9.1.0541: failing test with Vim configured without channel
  * 9.1.0540: Unused assignment in sign_define_cmd()
    runtime(doc): add page-scrolling keys to index.txt
    runtime(doc): add reference to xterm-focus-event from
    FocusGained/Lost
  * 9.1.0539: Not enough tests for what v9.1.0535 fixed
    runtime(doc): clarify how to re-init csv syntax file
  * 9.1.0538: not possible to assign priority when defining a sign
  * 9.1.0537: signed number detection for CTRL-X/A can be improved
  * 9.1.0536: filetype: zone files are not recognized
  * 9.1.0535: newline escape wrong in ex mode
    runtime(man): honor cmd modifiers before `g:ft_man_open_mode`
    runtime(man): use `nnoremap` to map to Ex commands
  * 9.1.0534: completion wrong with fuzzy when cycling back to original
    runtime(syntax-tests): Abort and report failed cursor progress
    runtime(syntax-tests): Introduce self tests for screen dumping
    runtime(syntax-tests): Clear and redraw the ruler line with
    the shell info
    runtime(syntax-tests): Allow for folded and wrapped lines in
    syntax test files
  * 9.1.0533: Vim9: need more tests for nested objects equality
    CI: Pre-v* 9.0.0110 versions generate bogus documentation tag entries
    runtime(doc): Remove wrong help tag CTRL-SHIFT-CR
  * 9.1.0532: filetype: Cedar files not recognized
    runtime(doc): document further keys that scroll page up/down
  * 9.1.0531: resource leak in mch_get_random()
    runtime(tutor): Fix wrong spanish translation
    runtime(netrw): fix remaining case of register clobber
  * 9.1.0530: xxd: MSVC warning about non-ASCII character
  * 9.1.0529: silent! causes following try/catch to not work
    runtime(rust): use shiftwidth() in indent script
  * 9.1.0528: spell completion message still wrong in translations
  * 9.1.0527: inconsistent parameter in Makefiles for Vim executable
  * 9.1.0526: Unwanted cursor movement with pagescroll at start of buffer
    runtime(doc): mention $XDG_CONFIG_HOME instead of $HOME/.config
  * 9.1.0525: Right release selects immediately when pum is truncated.
  * 9.1.0524: the recursive parameter in the *_equal functions can be removed
    runtime(termdebug): Add Deprecation warnings
  * 9.1.0523: Vim9: cannot downcast an object
  * 9.1.0522: Vim9: string(object) hangs for recursive references
  * 9.1.0521: if_py: _PyObject_CallFunction_SizeT is dropped in Python 3.13
  * 9.1.0520: Vim9: incorrect type checking for modifying lists
    runtime(manpager): avoid readonly prompt
  * 9.1.0519: MS-Windows: libvterm compilation can be optimized
  * 9.1.0518: initialize the random buffer can be improved
  * 9.1.0517: MS-Windows: too long lines in Make_mvc.mak
    runtime(terraform): Add filetype plugin for terraform
    runtime(dockerfile): enable spellchecking of comments in
    syntax script
    runtime(doc): rename variable for pandoc markdown support
    runtime(doc): In builtin overview use {buf} as param for
    appendbufline/setbufline
    runtime(doc): clarify, that register 1-* 9 will always be shifted
    runtime(netrw): save and restore register 0-* 9, a and unnamed
    runtime(termdebug): Refactored StartDebug_term and EndDebug
    functions
    runtime(java): Compose &amp;quot;g:java_highlight_signature&amp;quot; and
    &amp;quot;g:java_highlight_functions&amp;quot;
  * 9.1.0516: need more tests for nested dicts and list comparision
  * 9.1.0515: Vim9: segfault in object_equal()
  * 9.1.0514: Vim9: issue with comparing objects recursively
    runtime(termdebug): Change some variables to Enums
    runtime(vim): Update base-syntax, fix function tail comments
  * 9.1.0513: Vim9: segfault with object comparison
- Update to 9.1.0512:
  * Mode message for spell completion doesn't match allowed keys
  * CursorMovedC triggered wrongly with setcmdpos()
  * update runtime files
  * CI: test_gettext fails on MacOS14 + MSVC Win
  * not possible to translate Vim script messages
  * termdebug plugin can be further improved
  * add gomod filetype plugin
  * hard to detect cursor movement in the command line
  * Optionally highlight parameterised types
  * filetype: .envrc &amp;amp; .prettierignore not recognized
  * filetype: Faust files are not recognized
  * inner-tag textobject confused about &amp;quot;&amp;gt;&amp;quot; in attributes
  * cannot use fuzzy keyword completion
  * Remove the group exclusion list from @javaTop
  * wrong return type for execute() function
  * MS-Windows: too much legacy code
  * too complicated mapping restore in termdebug
  * simplify mapping
  * cannot switch buffer in a popup
  * MS-Windows: doesn't handle symlinks properly
  * getcmdcompltype() interferes with cmdline completion
  * termdebug can be further improved
  * update htmldjango detection
  * Improve Turkish documentation
  * include a simple csv filetype and syntax plugin
  * include the the simple nohlsearch package
  * matched text is highlighted case-sensitively
  * Matched text isn't highlighted in cmdline pum
  * Fix typos in several documents
  * clarify when text properties are cleared
  * improve the vim-shebang example
  * revert unintended formatting changes for termdebug
  * Add a config variable for commonly used compiler options
  * Wrong matched text highlighted in pum with 'rightleft'
  * bump length of character references in syntax script
  * properly check mapping variables using null_dict
  * fix KdlIndent and kdlComment in indent script
  * Test for patch 9.1.0489 doesn't fail without the fix
  * Fold multi-line comments with the syntax kind of &amp;amp;fdm
  * using wrong type for PlaceSign()
  * filetype: Vim-script files not detected by shebang line
  * revert unintended change to zip#Write()
  * add another tag for vim-shebang feature
  * Cmdline pum doesn't work properly with 'rightleft'
  * minor style problems with patch 9.1.0487
  * default completion may break with fuzzy
  * Wrong padding for pum &amp;quot;kind&amp;quot; with 'rightleft'
  * Update base-syntax, match shebang lines
  * MS-Windows: handle files with spaces properly
  * Restore HTML syntax file tests
  * completed item not update on fuzzy completion
  * filetype: Snakemake files are not recognized
  * make TermDebugSendCommand() a global function again
  * close all buffers in the same way
  * Matched text shouldn't be highlighted in &amp;quot;kind&amp;quot; and &amp;quot;menu&amp;quot;
  * fix wrong helptag for :defer
  * Update base-syntax, match :sleep arg
  * include Georgian keymap
  * Sorting of completeopt+=fuzzy is not stable
  * correctly test for windows in NetrwGlob()
  * glob() on windows fails with [] in directory name
  * rewrite mkdir() doc and simplify {flags} meaning
  * glob() not sufficiently tested
  * update return type for job_info()
  * termdebug plugin needs more love
  * correct return types for job_start() and job_status()
  * Update base-syntax, match :catch and :throw args
  * Include element values in non-marker annotations
  * Vim9: term_getjob() throws an exception on error
  * fuzzy string matching executed when not needed
  * fuzzy_match_str_with_pos() does unnecessary list operations
  * restore description of &amp;quot;$&amp;quot; in col() and virtcol()
  * deduplicate getpos(), line(), col(), virtcol()
  * Update g:vimsyn_comment_strings dump file tests
  * Use string interpolation instead of string concat
  * potential deref of NULL pointer in fuzzy_match_str_with_pos
  * block_editing errors out when using &amp;lt;enter&amp;gt;
  * Update base-syntax, configurable comment string highlighting
  * fix typos in syntax.txt
  * Cannot see matched text in popup menu
  * Update base-syntax, match multiline continued comments
  * clarify documentation for &amp;quot;v&amp;quot; position at line()
  * cmod_split modifier is always reset in term_start()
  * remove line-continuation characters
  * use shiftwidth() instead of &amp;amp;tabstop in indent script
  * Remove orphaned screen dump files
  * include syntax, indent and ftplugin files
  * CI: Test_ColonEight() fails on github runners
  * add missing Enabled field in syntax script
  * basic svelte ftplugin file
  * term_start() does not clear vertical modifier
  * fix mousemodel restoration by comparing against null_string
  * Added definitions of Vim scripts and plugins
  * Exclude lambda expressions from _when_ _switch-case_ label clauses
  * Fix saved_mousemodel check
  * Inconsistencies between functions for option flags
  * Crash when using autocmd_get() after removing event inside autocmd
  * Fix small style issues
  * add return type info for Vim function descriptions
  * Update Italian Vim manpage
  * disable the q mapping
  * Change 'cms' for C++ to '// %s'
  * fix type mismatch error
  * Fix wrong email address
  * convert termdebug plugin to Vim9 script
- Update to 9.1.0470:
  * tests Test_ColonEight_MultiByte() fails sporadically
  * Cannot have buffer-local value for 'completeopt'
  * GvimExt does not consult HKEY_CURRENT_USER
  * typos in some comments
  * runtime(vim): Update base-syntax, allow whitespace before
    :substitute pattern
  * Missing comments for fuzzy completion
  * runtime(man): update Vim manpage
  * runtime(comment): clarify the usage of 'commentstring' option
    value
  * runtime(doc): clarify how fuzzy 'completeopt' should work
  * runtime(netrw): prevent accidental data loss
  * missing filecopy() function
  * no whitespace padding in commentstring option in ftplugins
  * no fuzzy-matching support for insert-completion
  * eval5() and eval7 are too complex
  * too many strlen() calls in drawline.c
  * filetype lintstagedrc files are not recognized
  * Vim9 import autoload does not work with symlink
  * Coverity complains about division by zero
  * tests test_gui fails on Wayland
  * Left shift is incorrect with vartabstop and shiftwidth=0
  * runtime(doc): clarify 'shortmess' flag &amp;quot;S&amp;quot;
  * MS-Windows compiler warning for size_t to int conversion
  * runtime(doc): include some vim9 script examples in the help
  * minor issues in test_filetype with rasi test
  * filetype rasi files are not recognized
  * runtime(java): Improve the matching of lambda expressions
  * Configure checks for libelf unnecessarily
  * No test for escaping '&amp;lt;' with shellescape()
  * check.vim complains about overlong comment lines
  * translation(it): Update Italian translation
  * evalc. code too complex
  * MS-Windows Compiler warnings
- Update to 9.1.0448:
  * compiler warning in eval.c
  * remove remaining css code
  * Add ft_hare.txt to Reference Manual TOC
  * re-generate vim syntax from generator
  * fix syntax vim bug
  * completion may be wrong when deleting all chars
  * getregionpos() inconsistent for partly-selected multibyte char
  * fix highlighting nested and escaped quotes in string props
  * remove the indent plugin since it has too many issues
  * update Debian runtime files
  * Coverity warning after 9.1.0440
  * Not enough tests for getregion() with multibyte chars
  * Can't use blockwise selection with width for getregion()
  * update outdated syntax files
  * fix floating_modifier highlight
  * hare runtime files outdated
  * getregionpos() can't properly indicate positions beyond eol
  * function get_lval() is too long
  * Cannot filter the history
  * Wrong Ex command executed when :g uses '?' as delimiter
  * support floating_modifier none; revert broken highlighting
  * Motif requires non-const char pointer for XPM  data
  * Crash when using '?' as separator for :s
  * filetype: cygport files are not recognized
  * make errors trying to access autoload/zig
  * Wrong yanking with exclusive selection and ve=all
  * add missing help tags file
  * Ancient XPM preprocessor hack may cause build errors
  * include basic rescript ftplugin file
  * eval.c is too long
  * getregionpos() doesn't handle one char selection
  * check for gdb file/dir before using as buffer name
  * refactor zig ftplugin, remove auto format
  * Coverity complains about eval.c refactor
  * Tag guessing leaves wrong search history with very short names
  * some issues with termdebug mapping test
  * update matchit plugin to v1.20
  * too many strlen() calls in search.c
  * set commentstring option
  * update vb indent plugin as vim9script
  * filetype: purescript files are not recognized
  * filetype: slint files are not recognized
  * basic nim ftplugin file for comments
  * Add Arduino ftplugin and indent files
  * include basic typst ftplugin file
  * include basic prisma ftplugin file
  * include basic v ftplugin for comment support
  * getregionpos() wrong with blockwise mode and multibyte
  * function echo_string_core() is too long
  * hyprlang files are not recognized
  * add basic dart ftplugin file
  * basic ftplugin file for graphql
  * mention comment plugin at :h 'commentstring'
  * set commentstring for sql files in ftplugin
  * :browse oldfiles prompts even with single entry
  * eval.c not sufficiently tested
  * clarify why E195 is returned
  * clarify temporary file clean up
  * fix :NoMatchParen not working
  * Cannot move to previous/next rare word
  * add basic ftplugin file for sshdconfig
  * if_py: find_module has been removed in Python 3.12.0a7
  * some screen dump tests can be improved
  * Some functions are not tested
  * clarify instal instructions for comment package
  * Unable to leave long line with 'smoothscroll' and 'scrolloff'
  * fix typo in vim9script help file
  * Remove trailing spaces
  * clarify {special} argument for shellescape()
- update to 9.1.0413
  * smoothscroll may cause infinite loop
  * add missing entries for the keys CTRL-W g&amp;lt;Tab&amp;gt; and &amp;lt;C-Tab&amp;gt;
  * update vi_diff.txt: add default value for 'flash'
  * typo in regexp_bt.c in DEBUG code
  * allow indented commands
  * Fix wrong define regex in ftplugin
  * Filter out non-Latin-1 characters for syntax tests
  * prefer scp over pscp
  * fix typo in usr_52.txt
  * too long functions in eval.c
  * warning about uninitialized variable
  * too many strlen() calls in the regexp engine
  * E16 fix, async keyword support for define
  * Stuck with long line and half-page scrolling
  * Divide by zero with getmousepos() and 'smoothscroll'
  * update and remove  some invalid links
  * update translation of xxd manpage
  * Recursively delete directories by default with netrw delete command
  * Strive to remain compatible for at least Vim 7.0
  * tests: xxd buffer overflow fails on 32-bit
  * Stop handpicking syntax groups for @javaTop
  * [security] xxd: buffer-overflow with specific flags
  * Vim9: not able to import file from start dir
  * filetype: mdd files detected as zsh filetype
  * filetype: zsh module files are not recognized
  * Remove hardcoded private.ppk logic from netrw
  * Vim9: confusing error message for unknown type
  * block_editing errors out when using del
  * add new items to scripts section in syntax plugin
  * Vim9: imported vars are not properly type checked
  * Wrong display with 'smoothscroll' when changing quickfix list
  * filetype: jj files are not recognized
  * getregionpos() may leak memory on error
  * The CODEOWNERS File is not useful
  * Remove and cleanup Win9x legacy from netrw
  * add MsgArea to 'highlight' option description
  * Cannot get a list of positions describing a region
  * Fix digit separator in syntax script for octals and floats
  * Update link to Wikipedia Vi page
  * clear $MANPAGER in ftplugin before shelling out
  * Fix typos in help documents
  * 'viewdir' not respecting $XDG_CONFIG_HOME
  * tests: Vim9 debug tests may be flaky
  * correct getscriptinfo() example
  * Vim9: could improve testing
  * test_sound fails on macos-12
  * update Serbian menu
  * update Slovak menu
  * update Slovenian menu
  * update Portuguese menu
  * update Dutch menu
  * update Korean menu
  * update Icelandic menu
  * update Czech menu
  * update Afrikaans menu
  * update German menu
  * filetype: inko files are not recognized
  * filetype: templ files are not recognized
  * cursor() and getregion() don't handle v:maxcol well
  * Vim9: null value tests not sufficient
  * update Catalan menu
  * filetype: stylus files not recognized
  * update spanish menu localization
  * regenerate helptags
  * Vim9: crash with null_class and null_object
  * Add tags about lazyloading of menu
  * tests: vt420 terminfo entry may not be found
  * filetype: .out files recognized as tex files
  * filetype: Kbuild files are not recognized
  * cbuffer and similar commands don't accept a range
  * Improve the recognition of the &amp;quot;indent&amp;quot; method declarations
  * Fix a typo in usr_30.txt
  * remove undefined var s:save_cpoptions and add include setting
  * missing setlocal in indent plugin
  * Calculating line height for unnecessary amount of lines
  * improve syntax file performance
  * There are a few typos
  * Vim9: no comments allowed after class vars
  * CI: remove trailing white space in documentation
  * Formatting text wrong when 'breakindent' is set
  * Add oracular (24.10) as Ubuntu release name
  * Vim9: Trailing commands after class/enum keywords ignored
  * tests: 1-second delay after Test_BufEnter_botline()
  * update helptags for jq syntax
  * include syntax, ftplugin and compiler plugin
  * fix typo synconcealend -&amp;gt; synconcealed
  * include a simple comment toggling plugin
  * wrong botline in BufEnter
  * clarify syntax vs matching mechanism
  * fix undefined variable in indent plugin
  * ops.c code uses too many strlen() calls
  * Calling CLEAR_FIELD() on the same struct twice
  * Vim9: compile_def_function() still too long
  * Update Serbian messages
  * clarify the effect of setting the shell to powershell
  * Improve the recognition of the &amp;quot;style&amp;quot; method declarations
  * Vim9: problem when importing autoloaded scripts
  * compile_def_function is too long
  * filetype: ondir files are not recognized
  * Crash when typing many keys with D- modifier
  * tests: test_vim9_builtin is a bit slow
  * update documentation
  * change the download URL of &amp;quot;libsodium&amp;quot;
  * tests: test_winfixbuf is a bit slow
  * Add filetype, syntax and indent plugin for Astro
  * expanding rc config files does not work well
  * Vim9: vim9type.c is too complicated
  * Vim9: does not handle autoloaded variables well
  * minor spell fix in starting.txt
  * wrong drawing in GUI with setcellwidth()
  * Add include and suffixesadd
  * Page scrolling should place cursor at window boundaries
  * align command line table
  * minor fixes to starting.txt
  * fix comment definition in filetype plugin
  * filetype: flake.lock files are not recognized
  * runtime(uci): No support for uci file types
  * Support &amp;quot;g:ftplugin_java_source_path&amp;quot; with archived files
  * tests: Test_autoload_import_relative_compiled fails on Windows
  * Finding cmd modifiers and cmdline-specials is inefficient
  * No test that completing a partial mapping clears 'showcmd'
  * tests: test_vim9_dissamble may fail
  * Vim9: need static type for typealias
  * X11 does not ignore smooth scroll event
  * A few typos in test_xdg when testing gvimrc
  * Patch v9.1.0338 fixed sourcing a script with import
  * Problem: gvimrc not sourced from XDG_CONFIG_HOME
  * Cursor wrong after using setcellwidth() in terminal
  * 'showcmd' wrong for partial mapping with multibyte
  * tests: test_taglist fails when 'helplang' contains non-english
  * Problem: a few memory leaks are found
  * Problem: Error with matchaddpos() and empty list
  * tests: xdg test uses screen dumps
  * Vim9: import through symlinks not correctly handled
  * Missing entry for XDG vimrc file in :version
  * tests: typo in test_xdg
  * runtime(i3config/swayconfig): update syntax scripts
  * document pandoc compiler and enable configuring arguments
  * String interpolation fails for List type
  * No test for highlight behavior with 'ambiwidth'
  * tests: test_xdg fails on the appimage repo
  * tests: some assert_equal() calls have wrong order of args
  * make install does not install all files
  * runtime(doc): fix typos in starting.txt

- Remove patch to fix bsc#1220618:
  * vim-8.2.3607-revert-gtk3-code-removal.patch
- This patch introduced this bug that caused Vim to use significantly more CPU.

Package ca-certificates-mozilla was updated:

- Updated to 2.68 state of Mozilla SSL root CAs (bsc#1227525)  - Added: FIRMAPROFESIONAL CA ROOT-A WEB
  - Distrust: GLOBALTRUST 2020

- Updated to 2.66 state of Mozilla SSL root CAs (bsc#1220356)
  Added:
  - CommScope Public Trust ECC Root-01
  - CommScope Public Trust ECC Root-02
  - CommScope Public Trust RSA Root-01
  - CommScope Public Trust RSA Root-02
  - D-Trust SBR Root CA 1 2022
  - D-Trust SBR Root CA 2 2022
  - Telekom Security SMIME ECC Root 2021
  - Telekom Security SMIME RSA Root 2023
  - Telekom Security TLS ECC Root 2020
  - Telekom Security TLS RSA Root 2023
  - TrustAsia Global Root CA G3
  - TrustAsia Global Root CA G4
  Removed:
  - Autoridad de Certificacion Firmaprofesional CIF A62634068
  - Chambers of Commerce Root - 2008
  - Global Chambersign Root - 2008
  - Security Communication Root CA
  - Symantec Class 1 Public Primary Certification Authority - G6
  - Symantec Class 2 Public Primary Certification Authority - G6
  - TrustCor ECA-1
  - TrustCor RootCert CA-1
  - TrustCor RootCert CA-2
  - VeriSign Class 1 Public Primary Certification Authority - G3
  - VeriSign Class 2 Public Primary Certification Authority - G3
- remove-trustcor.patch: removed, now upstream
- do a versioned obsoletes of &amp;quot;openssl-certs&amp;quot;.

Package libzypp was updated:

- Url: queryparams without value should not have a trailing &amp;quot;=&amp;quot;.- version 16.22.15 (0)

- Url query part: `=` is a safe char in value (bsc#1234304)
  Some CDN auth token implementations require a `=` within the
  query parameters value not to be %-encoded.
- version 16.22.14 (0)

Package apparmor was updated:

- Add apparmor-fix-ping6-denied.patch to allow ping to use  IPv6 RAW sockets ( bsc#1230541 ).

Package util-linux-systemd was updated:

- agetty: Prevent login cursor escape (bsc#1194818,  util-linux-agetty-prevent-cursor-escape.patch).

- Don't delete binaries not common for all architectures. Create an
  util-linux-extra subpackage instead, so users of third party
  tools can use them. (bsc#1222285)

- fix Xen virtualization type misidentification bsc#1215918
  lscpu-fix-parameter-order-for-ul_prefix_fopen.patch

Package google-guest-agent was updated:

- Update to version 20241011.01 (bsc#1231775, bsc#1231776)  * SUSE no overwrite bug fix, Ubuntu 18.04 exception (#451)
- from version 20241011.00
  * Skip MDS setup by default for this release (#450)
- from version 20241010.01
  * Revert &amp;quot;network/netplan: Adjust link-local accordingly (#443)&amp;quot; (#448)
  * Set enable regardless of previous check failed or not (#447)
- from version 20241009.03
  * Avoid unnecessary reloads, check before overwriting configs (#446)
- from version 20241009.02
  * network/netplan: Do generate instead of apply (#445)
- from version 20241009.01
  * Skip SetupInterfaces if configs are already applied (#444)
  * network/netplan: Adjust link-local accordingly (#443)
  * Repeated logging could be mistaken for a recurring issue,
    log mds mtls endpoint error only once (#439)
  * Retry MDS PUT operation, reload netplan/networkctl
    only if configs are changed (#438)
  * Log interface state after setting up network (#437)
  * network: Debian 12 rollback only if default netplan is ok (#436)
- from version 20240930.01
  * Change mtls mds defaults, update log message to assure error is harmless (#434)
- from version 20240930.00
  * network: Restore Debian 12 netplan configuration. (#433)
  * network: Remove primary NIC left over configs. (#432)
  * Update VLAN interfaces format to match with MDS (#431)
  * Fix panics in agent when setting up VLAN with netplan (#430)
  * Add VLAN NIC support for NetworkManager (#429)
  * Fix debian12 netplan config issue, use ptr receiver (#428)
  * Update README to reflect new network manager changes (#427)
  * Introduce a configuration toggle for enabling/disabling cloud logging (#413)
  * Adapt and update config key to be consistent with MDS (#426)
  * Allow users to enable/disable the mds mtls via metadata key (#423)
  * Make primary nic management config consistent across all network managers (#422)
  * Document disabling account manager on AD (#421)
  * Update README with MDS MTLS docs (#418)
  * Avoid writing configuration files when they already exist on wicked and (#410)
  * Update golang.org/x/net dependencies to catch up on CVEs (#412)
  * Get rid of deperecated dependencies in snapshot service generate code (#411)
  * Fix where agent panics on nil event (#409)
  * Configure primary nic if only set in cfg file (#408)
  * Update NIC management strategy (#402)
  * Only release dhclient leases for an interface if the
    respective dhclient is still running (#407)
  * Disable OS Login without pruning off any extra suffix. (#400)
  * Skip root cert rotation if installed once (#405)
  * Add ipv6 support to guest agent (#404)
  * Update Accounts documentation (#403)
  * Update google-startup-scripts.service to enable logging (#399)
  * Network subsystem remove os rules (#396)
  * oslogin: Don't remove sshca watcher when oslogin is disabled (#398)
  * Update dependencies to catch up on CVE fixes (#397)
  * Network manager netplan implementation (#386)
  * Update dependencies to catch up on CVE fixes (#391)
  * Log current available routes on error (#388)
  * Fix command monitor bugs (#389)
  * windows account: Ignore &amp;quot;user already belogs to group&amp;quot; error (#387)
  * Add more error logging in snapshot handling requests, use common retry util (#384)
  * All non-200 status code from MDS should raise error (#383)
  * Change metadata key to enable-oslogin-certificates (#382)
  * Update dhclient pid/lease file directory to abide apparmor rules (#381)
  * Add COS homedir-gid patch to upstream. (#365)
  * Add require-oslogin-certificates logic to disable keys (#368)
  * systemd-networkd: Support Debian 12's version (#372)
  * Minor update typo in comment (#380)
  * NetworkManager: Only set secondary interfaces as up (#378)
  * address manager: Make sure we check for oldMetadata (#375)
  * network: Early setup network (#374)
  * NetworkManager: Fix ipv6 and ipv4 mode attribute (#373)
  * Network Manager: Make sure we clean up ifcfg files (#371)
  * metadata script runner: Fix script download (#370)
  * oslogin: Avoid adding extra empty line at the end of /etc/security/group.conf (#369)
  * Dynamic vlan (#361)
  * Check for nil response (#366)
  * Create NetworkManager implementation (#362)
  * Skip interface manager on Windows (#363)
  * network: Remove ignore setup (#360)
  * Create wicked network service implementation and its respective unit (#356)
  * Update metadata script runner, add tests (#357)
  * Refactor guest-agent to use common retry util (#355)
  * Flush logs before exiting #358 (#359)
  * Create systemd-networkd unit tests. (#354)
  * Update network manager unit tests (#351)
  * Implement retry util (#350)
  * Refactor utils package to not dump everything unrelated into one file (#352)
  * Set version on metadata script runner (#353)
  * Implement cleanup of deprecated configuration directives (#348)
  * Ignore DHCP offered routes only for secondary nics (#347)
  * Deprecate DHClient in favor of systemd-networkd (#342)
  * Generate windows and linux licenses (#346)
  * Remove quintonamore from OWNERS (#345)
  * Delete integration tests (#343)

- Update to version 20240816.00
  * Add configuration toggle to enable/disable use
    of OS native certificate stores (#419)
  * Fix dependencies in stable branch #412 (#415)
  * Update dep: golang.org/x/crypto to v0.17.0
  * Update dep: google.golang.org/protobuf to 1.33.0
  * Update dep: golang.org/x/net to 0.17.0
  * Update dep: google.golang.org/grpc to v1.57.1
- from version 20240813.00
  * Update README with MDS MTLS docs (#418)
- from version 20240808.01
  * Avoid writing configuration files when they already
    exist on wicked and NetworkManager (#410)
- from version 20240808.00
  * Update golang.org/x/net dependencies
    to catch up on CVEs (#412)
- from version 20240805.00
  * Get rid of deperecated dependencies in
    snapshot service generate code (#411)
- Drop dont_overwrite_ifcfg.patch, fixed upstream

- Update to version 20240802.00
  * Fix where agent panics on nil event (#409)
- from version 20240801.00
  * Configure primary nic if only set in cfg file (#408)
  * Update NIC management strategy (#402)
  * Only release dhclient leases for an interface if the respective dhclient is still running (#407)
  * Disable OS Login without pruning off any extra suffix. (#400)
  * Skip root cert rotation if installed once (#405)
  * Add ipv6 support to guest agent (#404)
  * Update Accounts documentation (#403)
  * Update google-startup-scripts.service to enable logging (#399)
  * Network subsystem remove os rules (#396)
  * oslogin: don't remove sshca watcher when oslogin is disabled (#398)
  * Update dependencies to catch up on CVE fixes (#397)
  * Network manager netplan implementation (#386)
  * Update dependencies to catch up on CVE fixes (#391)
  * Log current available routes on error (#388)
  * Fix command monitor bugs (#389)
  * Windows account: ignore &amp;quot;user already belogs to group&amp;quot; error (#387)
  * Add more error logging in snapshot handling requests, use common retry util (#384)
  * All non-200 status code from MDS should raise error (#383)
  * Change metadata key to enable-oslogin-certificates (#382)
  * Update dhclient pid/lease file directory to abide apparmor rules (#381)
  * Add COS homedir-gid patch to upstream. (#365)
  * Add require-oslogin-certificates logic to disable keys (#368)
  * systemd-networkd: support debian 12's version (#372)
  * Minor update typo in comment (#380)
  * NetworkManager: only set secondary interfaces as up (#378)
  * address manager: make sure we check for oldMetadata (#375)
  * network: early setup network (#374)
  * NetworkManager: fix ipv6 and ipv4 mode attribute (#373)
  * Network Manager: make sure we clean up ifcfg files (#371)
  * metadata script runner: fix script download (#370)
  * oslogin: avoid adding extra empty line at the end of /etc/security/group.conf (#369)
  * Dynamic vlan (#361)
  * Check for nil response (#366)
  * Create NetworkManager implementation (#362)
  * Skip interface manager on Windows (#363)
  * network: remove ignore setup (#360)
  * Create wicked network service implementation and its respective unit (#356)
  * Update metadata script runner, add tests (#357)
  * Refactor guest-agent to use common retry util (#355)
  * Flush logs before exiting #358 (#359)
  * Create systemd-networkd unit tests. (#354)
  * Update network manager unit tests (#351)
  * Implement retry util (#350)
  * Refactor utils package to not dump everything unrelated into one file (#352)
  * Set version on metadata script runner (#353)
  * Implement cleanup of deprecated configuration directives (#348)
  * Ignore DHCP offered routes only for secondary nics (#347)
  * Deprecate DHClient in favor of systemd-networkd (#342)
  * Generate windows and linux licenses (#346)
  * Remove quintonamore from OWNERS (#345)
  * Delete integration tests (#343)
- from version 20240716.00
  * Update dep: golang.org/x/crypto to v0.17.0
  * Update dep: google.golang.org/protobuf to 1.33.0
  * Update dep: golang.org/x/net to 0.17.0
  * Update dep: google.golang.org/grpc to v1.57.1

- Update to version 20240701.00
  * Update google-startup-scripts.service to enable logging (#399)

- Update to version 20240611.01
  * Network subsystem remove os rules (#396)
  * oslogin: don't remove sshca watcher when oslogin is disabled (#398)
  * update dependencies to catch up on CVE fixes (#397)
  * Network manager netplan implementation (#386)
  * update dependencies to catch up on CVE fixes (#391)
  * Log current available routes on error (#388)
  * Fix command monitor bugs (#389)
  * windows account: ignore &amp;quot;user already belogs to group&amp;quot; error (#387)
  * Add more error logging in snapshot handling requests, use common retry util (#384)
  * All non-200 status code from MDS should raise error (#383)
  * change metadata key to enable-oslogin-certificates (#382)
  * Update dhclient pid/lease file directory to abide apparmor rules (#381)
  * Add COS homedir-gid patch to upstream. (#365)
  * Add require-oslogin-certificates logic to disable keys (#368)
  * systemd-networkd: support debian 12's version (#372)
  * Minor update typo in comment (#380)
  * NetworkManager: only set secondary interfaces as up (#378)
  * address manager: make sure we check for oldMetadata (#375)
  * network: early setup network (#374)
  * NetworkManager: fix ipv6 and ipv4 mode attribute (#373)
  * Network Manager: make sure we clean up ifcfg files (#371)
  * metadata script runner: fix script download (#370)
  * oslogin: avoid adding extra empty line at the end of /etc/security/group.conf (#369)
  * Dynamic vlan (#361)
  * Check for nil response (#366)
  * Create NetworkManager implementation (#362)
  * Skip interface manager on Windows (#363)
  * network: remove ignore setup (#360)
  * Create wicked network service implementation and its respective unit (#356)
  * Update metadata script runner, add tests (#357)
  * Refactor guest-agent to use common retry util (#355)
  * Flush logs before exiting #358 (#359)
  * Create systemd-networkd unit tests. (#354)
  * Update network manager unit tests (#351)
  * Implement retry util (#350)
  * Refactor utils package to not dump everything unrelated into one file (#352)
  * Set version on metadata script runner (#353)
  * Implement cleanup of deprecated configuration directives (#348)
  * ignore DHCP offered routes only for secondary nics (#347)
  * Deprecate DHClient in favor of systemd-networkd (#342)
  * Generate windows and linux licenses (#346)
  * Remove quintonamore from OWNERS (#345)
  * Delete integration tests (#343)
- from version 20240528.00
  * update dep: golang.org/x/crypto to v0.17.0
  * update dep: google.golang.org/protobuf to 1.33.0
  * update dep: golang.org/x/net to 0.17.0
  * update dep: google.golang.org/grpc to v1.57.1

Package util-linux was updated:

- agetty: Prevent login cursor escape (bsc#1194818,  util-linux-agetty-prevent-cursor-escape.patch).

- Don't delete binaries not common for all architectures. Create an
  util-linux-extra subpackage instead, so users of third party
  tools can use them. (bsc#1222285)

Package systemd was updated:

Package runc was updated:

[ This was only ever released for SLES and Leap. ]- Update to runc v1.1.14. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.1.14&amp;gt;.
  Includes the patch for CVE-2024-45310. bsc#1230092
- Rebase patches:
  * 0001-bsc1221050-libct-seccomp-patchbpf-rm-duplicated-code.patch
  * 0002-bsc1221050-seccomp-patchbpf-rename-nativeArch-linuxA.patch
  * 0003-bsc1221050-seccomp-patchbpf-always-include-native-ar.patch
  * 0004-bsc1214960-nsenter-cloned_binary-remove-bindfd-logic.patch

[ This was only ever released for SLES and Leap. ]
- Update to runc v1.1.13. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.1.13&amp;gt;.
- Rebase patches:
  * 0001-bsc1221050-libct-seccomp-patchbpf-rm-duplicated-code.patch
  * 0002-bsc1221050-seccomp-patchbpf-rename-nativeArch-linuxA.patch
  * 0003-bsc1221050-seccomp-patchbpf-always-include-native-ar.patch
- Backport &amp;lt;https://github.com/opencontainers/runc/pull/3931&amp;gt; to fix a
  performance issue when running lots of containers, caused by systemd getting
  too many mount notifications. bsc#1214960
  + 0004-bsc1214960-nsenter-cloned_binary-remove-bindfd-logic.patch

Package iputils was updated:

- Bring back ifenslave binary bcs#1234224  * Add iputils-ifenslave.diff
  * Rebase iputils-disable-rarpd-rdisc.patch

- Resolve jsc#PED-9524
- Bump version to version s20161105 (bsc#1221439)
- This version can use ICMP datagram sockets without CAP_NET_RAW capabilites.
- Added iputils-disable-rarpd-rdisc.patch
  - disables building of rarpd and rdisc as they're provided by separate package (rarpd) in SLE12-SP5
  Full changelog:
  * ping: eliminate deadcode &amp;amp; simplify
  * ping: do not allow oversized packets to root
  * correctly initialize first hop
  * ping: fix ping -6 -I
  * arping,doc: fix documentation of -I
  * ping: fix error message when getting EACCES from connect()
  * renamed INSTALL to INSTALL.md
  * (re)structured INSTALL.md and transformed into markdown; added hint that installation into prefix has to be done with DESTDIR make variable and that there's no prefix support in configure, close #21
  * ping: Silence GCC warnings when building with -fstrict-aliasing
  * tftpd: Drop supplementary groups for root
  * libgcrypt: fix static linking
  * doc: Inserted a missing word
  * tracepath6: avoid redundant family variable
  * tracepath: borrow everything good from tracepath6
  * tracepath: switch to dual-stack operation
  * tracepath: remove now redundant tracepath6
  * docs: fix parallel build of manpages
  * ping: remove assignments of values that are never read
  * docs: remove references to ping6 and traceroute6
  * ping: work with older kernels that don't support ping sockets
  * Revert &amp;quot;ping_common.c: fix message flood when EPERM is encountered in ping&amp;quot;
  * reorder -I option parsing (boo#1057664)
  * ping: also bind the ICMP socket to the specific device
- tracepath6 is now symlink to tracepath.

- Add fix for ICMP datagram socket ping6-Fix-device-binding.patch
  (bsc#1196840, bsc#1199918, bsc#1199926, bsc#1199927).

- Remove 2 old patches (iputils-sec-ping-unblock.diff, iputils-ping-interrupt.diff)
  Although not documented, they both belong to bsc#674304. Fix from 2011 was
  resolved upstream in commit 810dd7f (&amp;quot;ping,ping6: Unmask signals on
  start-up.&amp;quot;) [1], released in s20121112.
- Update iputils-remove-bogus-check-required-for-2.4.9-kernels.patch
  (backport 4471ac6 to add changes in header files)
- Use git format for iputils-ping-fix-pmtu-for-ipv6.patch (required by
  %autosetup -p1)
- Use %autosetup -p1

- Backport license information from upstream (bnc#1082788):
  iputils-add-license-info.diff

- Backport iputils-ping-fix-pmtu-for-ipv6.patch from upstream
  to fix PMTU discovery in ping6. (bsc#1072460)

- Install rdisc as rdisc, do not use in.rdisc anymore (xinetd which
  was using in.* names is obsolete anyways)

- iputils: remove man pages of unused binaries: ninfod, pg3, rdisc
  (rdisc is in a separate package)

- Add systemd service for rarpd

- mark ping also verify not caps, as these are changed by the
  permissions package. (bsc#1065835)

- Reintroduce rarpd as subpackage
- Explicitly list content in filelist as we have two subpackages
  now

- Cleanup with spec-cleaner

- Update to version s20161105 (Changes taken from the RELNOTES file)
  * ping: eliminate deadcode &amp;amp; simplify
  * ping: do not allow oversized packets to root
  * correctly initialize first hop
  * ping: fix ping -6 -I
  * arping,doc: fix documentation of -I
  * ping: fix error message when getting EACCES from connect()
  * renamed INSTALL to INSTALL.md
  * (re)structured INSTALL.md and transformed into markdown; added hint that installation into prefix has to be done with DESTDIR make variable and that there's no prefix support in configure, close #21
  * ping: Silence GCC warnings when building with -fstrict-aliasing
  * tftpd: Drop supplementary groups for root
  * libgcrypt: fix static linking
  * doc: Inserted a missing word
  * tracepath6: avoid redundant family variable
  * tracepath: borrow everything good from tracepath6
  * tracepath: switch to dual-stack operation
  * tracepath: remove now redundant tracepath6
  * docs: fix parallel build of manpages
  * ping: remove assignments of values that are never read
  * docs: remove references to ping6 and traceroute6
  * ping: work with older kernels that don't support ping sockets
  * Revert &amp;quot;ping_common.c: fix message flood when EPERM is encountered in ping&amp;quot;
  * reorder -I option parsing (boo#1057664)
  * ping: also bind the ICMP socket to the specific device
- tracepath6 is now symlink to tracepath.

- Add ping6 symlink (boo#1017616)

- do not install rarpd and rarpd.8 manpage (comes from rarpd rpm currently)

- Update to version s20160308 (Changes taken from the RELNOTES file)
  * use syntax compatible with busybox date in Makefile
  * 'admin prohibited' should print !X not !S.
  * Makefile: use #define as in previous code changes
  * doc/Makefile: require bash, because we use pushd and popd
  * doc: don't timestamp manpages by default
  * ping: status() now returns received/transmitted instead of trans/recv
  * ping: don't mess with internals of struct msghdr
  * ping: ICMP error replies while errno &amp;lt; 0 is a hard error
  * ping: always use POSIX locale when parsing -i
  * ping: link against libm
  * made ping functions protocol independent
  * ping: perform dual-stack ping by default
  * ping: remove obsolete preprocessor directives
  * ping: avoid name clashes between IPv4 and IPv6 code
  * ping: merge all ping header files into a single one
  * ping: merge `ping6` command into `ping`
  * ping: refactor ping options
  * ping: refactor ping socket code
  * ping: merge IPv4 and IPv6 `pr_addr()`
  * ping: fix defines and libs in Makefile
  * ping: handle single protocol systems
  * iputils ping/ping6: Add a function to check if a packet is ours
  * ping: Add &amp;lt;linux/types.h&amp;gt; to fix compilation error.
  * ping6: Use GNUTLS API directly for MD5. (v2)
  * ping6: Use libgcrypt instead of gnutls for MD5.
  * Allow ping to use IPv6 addresses
  * ping,ping6 doc: More description on CAP_NET_RAW usage.
  * if IPv4 resolving fails fallback to ping6
  * ping: in usage print the 'ping -6' options as well
  * ping: allow option -4 which forces IPv4
  * combine sock and errno into a single structure
  * This patch allows running ping and ping6 without root privileges on
  * use better names for socket variables
  * tracepath,doc: fix corrupted tag
  * doc: ping: add missing options and remove ping6
  * ninfod: remove unused variables
  * ninfod: Regenerate configure by autoconf-2.69.
  * ninfod: libgcrypt support.
  * Fix building with musl
  * travis.yml: install nettle-dev
  * Allow using nettle instead of libgcrypt for MD5
  * avoid compiler warning caused by snapshot.h
  * make `getaddrinfo()` and `getnameinfo()` usage consistent
  * enable IDN by default
  * remove IPV4_TARGETS and IPV6_TARGETS
  * Use svg instead of png to get better image quality
  * spec: Configure before building ninfod.
  * spec: Fix date in %changelog.
  * make,spec: Add rpm target.
- Refreshed patches
  * iputils-ping-interrupt.diff
  * iputils-sec-ping-unblock.diff
- Remove ifenslave.c. It has been removed in the linux kernel commit
  b1098bbe1b24(&amp;quot;bonding: remove ifenslave.c from kernel source&amp;quot;).
  bonding can be done via iproute (netlink)
- dropped iputils-ifenslave.diff
- Append our CFLAGS to the upstream ones instead of overriding them.
- Cleanup old make command since the upstream Makefile does things right
  it seems.
- Use Provides: for old /{,s}bin utils to satisfy reverse dependencies.
- Install utilities to /bin and /sbin until reverse dependencies are
  properly fixed.
- Do not install tftp and traceroute to avoid conflicts with the tftp and
  traceroute packages. Stick to what iputils used to provide in the past.
- Remove iputils-traceroute6-stdint.diff patch since we are not building
  the traceroute* utilities.
- Install tracepath to /usr/bin. (boo#795788)

- Update to version s20150815
  * use syntax compatible with busybox date in Makefile
  * Makefile: use #define as in previous code changes
  * ping: status() now returns received/transmitted instead of trans/recv
  * ping: don't mess with internals of struct msghdr
  * tracepath,doc: fix corrupted tag
  * made ping functions protocol independent
  * Allow ping to use IPv6 addresses
  * if IPv4 resolving fails fallback to ping6
  * ping: in usage print the 'ping -6' options as well
  * ping: allow option -4 which forces IPv4
  * combine sock and errno into a single structure
  * This patch allows running ping and ping6 without root privileges on
  * use better names for socket variables
  * travis.yml: install nettle-dev
  * Allow using nettle instead of libgcrypt for MD5
  * avoid compiler warning caused by snapshot.h
  * make `getaddrinfo()` and `getnameinfo()` usage consistent
  * enable IDN by default
  * ping: perform dual-stack ping by default
  * remove IPV4_TARGETS and IPV6_TARGETS
  * ping: remove obsolete preprocessor directives
  * ping: avoid name clashes between IPv4 and IPv6 code
  * ping: merge all ping header files into a single one
  * ping: merge `ping6` command into `ping`
  * ping: refactor ping options
  * ping: refactor ping socket code
  * ping: merge IPv4 and IPv6 `pr_addr()`
  * Use svg instead of png to get better image quality
  * iputils ping/ping6: Add a function to check if a packet is ours
  * ping: Add &amp;lt;linux/types.h&amp;gt; to fix compilation error.
  * ping6: Use GNUTLS API directly for MD5. (v2)
  * ping6: Use libgcrypt instead of gnutls for MD5.
  * ninfod: Regenerate configure by autoconf-2.69.
  * ninfod: libgcrypt support.
  * spec: Configure before building ninfod.
  * spec: Fix date in %changelog.
  * make,spec: Add rpm target.
  * ping,ping6 doc: More description on CAP_NET_RAW usage.
- Update patches
  * iputils-s20101006-ping-interrupt.diff &amp;gt; iputils-ping-interrupt.diff
  * iputils-s20101006-sec-ping-unblock.diff &amp;gt; iputils-sec-ping-unblock.diff
  * iputils-remove-bogus-check-required-for-2.4.9-kernels.patch
- Update home project page and download Url
- Remove obsolete %clean section
- Remove UsrMerge process; it has been done for more than two
  openSUSE releases now

- Fix a bogus kernel version check (boo#927831):
  iputils-remove-bogus-check-required-for-2.4.9-kernels.patch

Package _product:sle-sdk-release was updated:

Package python-base was updated:

- Add CVE-2024-11168-validation-IPv6-addrs.patch  fixing bsc#1233307 (CVE-2024-11168,
  gh#python/cpython#103848): Improper validation of IPv6 and
  IPvFuture addresses.
- Add ipaddress module from https://github.com/phihag/ipaddress
- Remove -IVendor/ from python-config boo#1231795

- Stop using %%defattr, it seems to be breaking proper executable
  attributes on /usr/bin/ scripts (bsc#1227378).

Package grep was updated:

- port-recent-fix-to-older-pcre-version.patch: Don't assume that  a pcre_exec that returns PCRE_ERROR_NOMATCH leaves its sub
  argument alone. (bsc#1227099)

Package docker was updated:

- Update docker-buildx to v0.19.2. See upstream changelog online at  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.19.2&amp;gt;.
  Some notable changelogs from the last update:
  * &amp;lt;https://github.com/docker/buildx/releases/tag/v0.19.0&amp;gt;
  * &amp;lt;https://github.com/docker/buildx/releases/tag/v0.18.0&amp;gt;
- Update to Go 1.22.

- Add a new toggle file /etc/docker/suse-secrets-enable which allows users to
  disable the SUSEConnect integration with Docker (which creates special mounts
  in /run/secrets to allow container-suseconnect to authenticate containers
  with registries on registered hosts). bsc#1231348 bsc#1232999
  In order to disable these mounts, just do
    echo 0 &amp;gt; /etc/docker/suse-secrets-enable
  and restart Docker. In order to re-enable them, just do
    echo 1 &amp;gt; /etc/docker/suse-secrets-enable
  and restart Docker. Docker will output information on startup to tell you
  whether the SUSE secrets feature is enabled or not.
  * 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch

- Disable docker-buildx builds for SLES. It turns out that build containers
  with docker-buildx don't currently get the SUSE secrets mounts applied,
  meaning that container-suseconnect doesn't work when building images.
  bsc#1233819

- Add docker-integration-tests-devel subpackage for building and running the
  upstream Docker integration tests on machines to test that Docker works
  properly. Users should not install this package.
- docker-rpmlintrc updated to include allow-list for all of the integration
  tests package, since it contains a bunch of stuff that wouldn't normally be
  allowed.

- Remove DOCKER_NETWORK_OPTS from docker.service. This was removed from
  sysconfig a long time ago, and apparently this causes issues with systemd in
  some cases.

- Further merge docker and docker-stable specfiles to minimise the differences.
  The main thing is that we now include both halves of the
  Conflicts/Provides/Obsoletes dance in both specfiles.

- Update to docker-buildx v0.17.1 to match standalone docker-buildx package we
  are replacing. See upstream changelog online at
  &amp;lt;https://github.com/docker/buildx/releases/tag/v0.17.1&amp;gt;

- Allow users to disable SUSE secrets support by setting
  DOCKER_SUSE_SECRETS_ENABLE=0 in /etc/sysconfig/docker. bsc#1231348
  bsc#1232999

- Add %{_sysconfdir}/audit/rules.d to filelist.

- Mark docker-buildx as required since classic &amp;quot;docker build&amp;quot; has been
  deprecated since Docker 23.0. bsc#1230331
- Import docker-buildx v0.16.2 as a subpackage. Previously this was a separate
  package, but with docker-stable it will be necessary to maintain the packages
  together and it makes more sense to have them live in the same OBS package.
  bsc#1230333
- Make some minor name macro updates to help with the docker-stable package
  fork.

- Update to Docker 26.1.5-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/26.1/#2615&amp;gt;
  bsc#1230294
- This update includes fixes for:
  * CVE-2024-41110. bsc#1228324
  * CVE-2023-47108. bsc#1217070
  * CVE-2023-45142. bsc#1228553
- Rebase patches:
  * 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  * 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch
  * 0006-bsc1221916-update-to-patched-buildkit-version-to-fix.patch
  * 0007-bsc1214855-volume-use-AtomicWriteFile-to-save-volume.patch
  * cli-0001-docs-include-required-tools-in-source-tree.patch

Package avahi was updated:

- Add avahi-CVE-2024-52616.patch:  Backporting 1dade81c from upstream: Properly randomize query id
  of DNS packets.
  (CVE-2024-52616, bsc#1233420)

Package glib2 was updated:

- Add glib2-CVE-2024-52533.patch: fix a single byte buffer overflow  (boo#1233282 CVE-2024-52533 glgo#GNOME/glib#3461).

- Add glib2-gdbusmessage-cache-arg0.patch: cache the arg0 value in
  a dbus message. Fixes a possible use after free (boo#1224044).

Package bind was updated:

- Security Fixes:  * It is possible to craft excessively large numbers of resource
    record types for a given owner name, which has the effect of
    slowing down database processing. This has been addressed by
    only allowing a maximum of 100 records to be stored per name
    and type in a cache or zone database.
    (CVE-2024-1737)
    [bsc#1228256, bind-9.11-CVE-2024-1737.patch]
  * Validating DNS messages signed using the SIG(0) protocol (RFC
    2931) could cause excessive CPU load, leading to a
    denial-of-service condition. Support for SIG(0) message
    validation was removed from this version of named.
    (CVE-2024-1975)
    [bsc#1228257, bind-9.11-CVE-2024-1975.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-12-sp5-v20250103-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-12-sp5-v20250103-x86-64">
      <Branch Type="Product Name" Name="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
        <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
      </Branch>
    </Branch>
    <Branch Type="Product Version" Name="apparmor-parser-2.8.2-56.15.1">
      <FullProductName ProductID="apparmor-parser-2.8.2-56.15.1">apparmor-parser-2.8.2-56.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="bind-utils-9.11.22-3.57.1">
      <FullProductName ProductID="bind-utils-9.11.22-3.57.1">bind-utils-9.11.22-3.57.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ca-certificates-mozilla-2.68-12.46.1">
      <FullProductName ProductID="ca-certificates-mozilla-2.68-12.46.1">ca-certificates-mozilla-2.68-12.46.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="catatonit-0.1.3-1.8.1">
      <FullProductName ProductID="catatonit-0.1.3-1.8.1">catatonit-0.1.3-1.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-10.3.7-52.117.1">
      <FullProductName ProductID="cloud-regionsrv-client-10.3.7-52.117.1">cloud-regionsrv-client-10.3.7-52.117.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-plugin-gce-1.0.0-52.117.1">
      <FullProductName ProductID="cloud-regionsrv-client-plugin-gce-1.0.0-52.117.1">cloud-regionsrv-client-plugin-gce-1.0.0-52.117.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="containerd-1.7.23-16.97.1">
      <FullProductName ProductID="containerd-1.7.23-16.97.1">containerd-1.7.23-16.97.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="curl-8.0.1-11.101.1">
      <FullProductName ProductID="curl-8.0.1-11.101.1">curl-8.0.1-11.101.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="docker-26.1.5_ce-98.120.1">
      <FullProductName ProductID="docker-26.1.5_ce-98.120.1">docker-26.1.5_ce-98.120.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="expat-2.1.0-21.40.1">
      <FullProductName ProductID="expat-2.1.0-21.40.1">expat-2.1.0-21.40.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glib2-tools-2.48.2-12.43.1">
      <FullProductName ProductID="glib2-tools-2.48.2-12.43.1">glib2-tools-2.48.2-12.43.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-agent-20241011.01-1.41.3">
      <FullProductName ProductID="google-guest-agent-20241011.01-1.41.3">google-guest-agent-20241011.01-1.41.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-configs-20241121.00-1.35.1">
      <FullProductName ProductID="google-guest-configs-20241121.00-1.35.1">google-guest-configs-20241121.00-1.35.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-osconfig-agent-20240926.03-1.29.3">
      <FullProductName ProductID="google-osconfig-agent-20240926.03-1.29.3">google-osconfig-agent-20240926.03-1.29.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grep-2.16-4.9.1">
      <FullProductName ProductID="grep-2.16-4.9.1">grep-2.16-4.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-2.02-175.1">
      <FullProductName ProductID="grub2-2.02-175.1">grub2-2.02-175.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-i386-pc-2.02-175.1">
      <FullProductName ProductID="grub2-i386-pc-2.02-175.1">grub2-i386-pc-2.02-175.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="grub2-x86_64-efi-2.02-175.1">
      <FullProductName ProductID="grub2-x86_64-efi-2.02-175.1">grub2-x86_64-efi-2.02-175.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="iputils-s20161105-11.6.2">
      <FullProductName ProductID="iputils-s20161105-11.6.2">iputils-s20161105-11.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kernel-default-4.12.14-122.237.1">
      <FullProductName ProductID="kernel-default-4.12.14-122.237.1">kernel-default-4.12.14-122.237.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ksh-93vu-19.3.2">
      <FullProductName ProductID="ksh-93vu-19.3.2">ksh-93vu-19.3.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libapparmor1-2.8.2-56.15.1">
      <FullProductName ProductID="libapparmor1-2.8.2-56.15.1">libapparmor1-2.8.2-56.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libavahi-client3-0.6.32-32.30.1">
      <FullProductName ProductID="libavahi-client3-0.6.32-32.30.1">libavahi-client3-0.6.32-32.30.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libavahi-common3-0.6.32-32.30.1">
      <FullProductName ProductID="libavahi-common3-0.6.32-32.30.1">libavahi-common3-0.6.32-32.30.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libbind9-161-9.11.22-3.57.1">
      <FullProductName ProductID="libbind9-161-9.11.22-3.57.1">libbind9-161-9.11.22-3.57.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libblkid1-2.33.2-4.45.2">
      <FullProductName ProductID="libblkid1-2.33.2-4.45.2">libblkid1-2.33.2-4.45.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcurl4-8.0.1-11.101.1">
      <FullProductName ProductID="libcurl4-8.0.1-11.101.1">libcurl4-8.0.1-11.101.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libdns1110-9.11.22-3.57.1">
      <FullProductName ProductID="libdns1110-9.11.22-3.57.1">libdns1110-9.11.22-3.57.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libexpat1-2.1.0-21.40.1">
      <FullProductName ProductID="libexpat1-2.1.0-21.40.1">libexpat1-2.1.0-21.40.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libfdisk1-2.33.2-4.45.2">
      <FullProductName ProductID="libfdisk1-2.33.2-4.45.2">libfdisk1-2.33.2-4.45.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgcc_s1-13.3.0+git8781-1.16.1">
      <FullProductName ProductID="libgcc_s1-13.3.0+git8781-1.16.1">libgcc_s1-13.3.0+git8781-1.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgio-2_0-0-2.48.2-12.43.1">
      <FullProductName ProductID="libgio-2_0-0-2.48.2-12.43.1">libgio-2_0-0-2.48.2-12.43.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libglib-2_0-0-2.48.2-12.43.1">
      <FullProductName ProductID="libglib-2_0-0-2.48.2-12.43.1">libglib-2_0-0-2.48.2-12.43.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgmodule-2_0-0-2.48.2-12.43.1">
      <FullProductName ProductID="libgmodule-2_0-0-2.48.2-12.43.1">libgmodule-2_0-0-2.48.2-12.43.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgobject-2_0-0-2.48.2-12.43.1">
      <FullProductName ProductID="libgobject-2_0-0-2.48.2-12.43.1">libgobject-2_0-0-2.48.2-12.43.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libirs161-9.11.22-3.57.1">
      <FullProductName ProductID="libirs161-9.11.22-3.57.1">libirs161-9.11.22-3.57.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libisc1107-9.11.22-3.57.1">
      <FullProductName ProductID="libisc1107-9.11.22-3.57.1">libisc1107-9.11.22-3.57.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libisccc161-9.11.22-3.57.1">
      <FullProductName ProductID="libisccc161-9.11.22-3.57.1">libisccc161-9.11.22-3.57.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libisccfg163-9.11.22-3.57.1">
      <FullProductName ProductID="libisccfg163-9.11.22-3.57.1">libisccfg163-9.11.22-3.57.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="liblwres161-9.11.22-3.57.1">
      <FullProductName ProductID="liblwres161-9.11.22-3.57.1">liblwres161-9.11.22-3.57.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libmount1-2.33.2-4.45.2">
      <FullProductName ProductID="libmount1-2.33.2-4.45.2">libmount1-2.33.2-4.45.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libopenssl1_0_0-1.0.2p-3.95.1">
      <FullProductName ProductID="libopenssl1_0_0-1.0.2p-3.95.1">libopenssl1_0_0-1.0.2p-3.95.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libopenssl1_1-1.1.1d-2.113.1">
      <FullProductName ProductID="libopenssl1_1-1.1.1d-2.113.1">libopenssl1_1-1.1.1d-2.113.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpcap1-1.8.1-10.6.1">
      <FullProductName ProductID="libpcap1-1.8.1-10.6.1">libpcap1-1.8.1-10.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython2_7-1_0-2.7.18-33.38.1">
      <FullProductName ProductID="libpython2_7-1_0-2.7.18-33.38.1">libpython2_7-1_0-2.7.18-33.38.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython3_4m1_0-3.4.10-25.145.1">
      <FullProductName ProductID="libpython3_4m1_0-3.4.10-25.145.1">libpython3_4m1_0-3.4.10-25.145.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython3_6m1_0-3.6.15-73.1">
      <FullProductName ProductID="libpython3_6m1_0-3.6.15-73.1">libpython3_6m1_0-3.6.15-73.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libruby2_1-2_1-2.1.9-19.9.1">
      <FullProductName ProductID="libruby2_1-2_1-2.1.9-19.9.1">libruby2_1-2_1-2.1.9-19.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsmartcols1-2.33.2-4.45.2">
      <FullProductName ProductID="libsmartcols1-2.33.2-4.45.2">libsmartcols1-2.33.2-4.45.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libstdc++6-13.3.0+git8781-1.16.1">
      <FullProductName ProductID="libstdc++6-13.3.0+git8781-1.16.1">libstdc++6-13.3.0+git8781-1.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsuseconnect-1.13.0-3.28.1">
      <FullProductName ProductID="libsuseconnect-1.13.0-3.28.1">libsuseconnect-1.13.0-3.28.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsystemd0-228-157.63.1">
      <FullProductName ProductID="libsystemd0-228-157.63.1">libsystemd0-228-157.63.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libudev1-228-157.63.1">
      <FullProductName ProductID="libudev1-228-157.63.1">libudev1-228-157.63.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libuuid1-2.33.2-4.45.2">
      <FullProductName ProductID="libuuid1-2.33.2-4.45.2">libuuid1-2.33.2-4.45.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libzypp-16.22.15-72.1">
      <FullProductName ProductID="libzypp-16.22.15-72.1">libzypp-16.22.15-72.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nss-certs-3.101.2-58.124.1">
      <FullProductName ProductID="mozilla-nss-certs-3.101.2-58.124.1">mozilla-nss-certs-3.101.2-58.124.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssl-1_0_0-1.0.2p-3.95.1">
      <FullProductName ProductID="openssl-1_0_0-1.0.2p-3.95.1">openssl-1_0_0-1.0.2p-3.95.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pam-1.1.8-24.59.1">
      <FullProductName ProductID="pam-1.1.8-24.59.1">pam-1.1.8-24.59.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python-2.7.18-33.38.1">
      <FullProductName ProductID="python-2.7.18-33.38.1">python-2.7.18-33.38.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python-base-2.7.18-33.38.1">
      <FullProductName ProductID="python-base-2.7.18-33.38.1">python-base-2.7.18-33.38.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python-bind-9.11.22-3.57.1">
      <FullProductName ProductID="python-bind-9.11.22-3.57.1">python-bind-9.11.22-3.57.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python-xml-2.7.18-33.38.1">
      <FullProductName ProductID="python-xml-2.7.18-33.38.1">python-xml-2.7.18-33.38.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-3.4.10-25.145.1">
      <FullProductName ProductID="python3-3.4.10-25.145.1">python3-3.4.10-25.145.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-base-3.4.10-25.145.1">
      <FullProductName ProductID="python3-base-3.4.10-25.145.1">python3-base-3.4.10-25.145.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-pyOpenSSL-17.1.0-4.29.1">
      <FullProductName ProductID="python3-pyOpenSSL-17.1.0-4.29.1">python3-pyOpenSSL-17.1.0-4.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-setuptools-40.6.2-4.24.1">
      <FullProductName ProductID="python3-setuptools-40.6.2-4.24.1">python3-setuptools-40.6.2-4.24.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-urllib3-1.25.10-3.40.1">
      <FullProductName ProductID="python3-urllib3-1.25.10-3.40.1">python3-urllib3-1.25.10-3.40.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python36-base-3.6.15-73.1">
      <FullProductName ProductID="python36-base-3.6.15-73.1">python36-base-3.6.15-73.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="regionServiceClientConfigGCE-4.2.0-5.18.1">
      <FullProductName ProductID="regionServiceClientConfigGCE-4.2.0-5.18.1">regionServiceClientConfigGCE-4.2.0-5.18.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="release-notes-sles-12.5.20241206-3.43.3">
      <FullProductName ProductID="release-notes-sles-12.5.20241206-3.43.3">release-notes-sles-12.5.20241206-3.43.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby2.1-2.1.9-19.9.1">
      <FullProductName ProductID="ruby2.1-2.1.9-19.9.1">ruby2.1-2.1.9-19.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby2.1-stdlib-2.1.9-19.9.1">
      <FullProductName ProductID="ruby2.1-stdlib-2.1.9-19.9.1">ruby2.1-stdlib-2.1.9-19.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="runc-1.1.14-16.57.1">
      <FullProductName ProductID="runc-1.1.14-16.57.1">runc-1.1.14-16.57.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="shadow-4.2.1-36.15.1">
      <FullProductName ProductID="shadow-4.2.1-36.15.1">shadow-4.2.1-36.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="sles-release-12.5-9.5.2">
      <FullProductName ProductID="sles-release-12.5-9.5.2">sles-release-12.5-9.5.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="sles-release-POOL-12.5-9.5.2">
      <FullProductName ProductID="sles-release-POOL-12.5-9.5.2">sles-release-POOL-12.5-9.5.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="sudo-1.8.27-4.51.1">
      <FullProductName ProductID="sudo-1.8.27-4.51.1">sudo-1.8.27-4.51.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suse-build-key-12.0-7.19.1">
      <FullProductName ProductID="suse-build-key-12.0-7.19.1">suse-build-key-12.0-7.19.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suseconnect-ng-1.13.0-3.28.1">
      <FullProductName ProductID="suseconnect-ng-1.13.0-3.28.1">suseconnect-ng-1.13.0-3.28.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suseconnect-ruby-bindings-1.13.0-3.28.1">
      <FullProductName ProductID="suseconnect-ruby-bindings-1.13.0-3.28.1">suseconnect-ruby-bindings-1.13.0-3.28.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-228-157.63.1">
      <FullProductName ProductID="systemd-228-157.63.1">systemd-228-157.63.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-sysvinit-228-157.63.1">
      <FullProductName ProductID="systemd-sysvinit-228-157.63.1">systemd-sysvinit-228-157.63.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="udev-228-157.63.1">
      <FullProductName ProductID="udev-228-157.63.1">udev-228-157.63.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="util-linux-2.33.2-4.45.2">
      <FullProductName ProductID="util-linux-2.33.2-4.45.2">util-linux-2.33.2-4.45.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="util-linux-systemd-2.33.2-4.45.2">
      <FullProductName ProductID="util-linux-systemd-2.33.2-4.45.2">util-linux-systemd-2.33.2-4.45.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-9.1.0836-17.38.1">
      <FullProductName ProductID="vim-9.1.0836-17.38.1">vim-9.1.0836-17.38.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-data-common-9.1.0836-17.38.1">
      <FullProductName ProductID="vim-data-common-9.1.0836-17.38.1">vim-data-common-9.1.0836-17.38.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wicked-0.6.77-3.53.1">
      <FullProductName ProductID="wicked-0.6.77-3.53.1">wicked-0.6.77-3.53.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wicked-service-0.6.77-3.53.1">
      <FullProductName ProductID="wicked-service-0.6.77-3.53.1">wicked-service-0.6.77-3.53.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="xfsprogs-4.15.0-3.28.1">
      <FullProductName ProductID="xfsprogs-4.15.0-3.28.1">xfsprogs-4.15.0-3.28.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-network-3.4.12-3.6.4">
      <FullProductName ProductID="yast2-network-3.4.12-3.6.4">yast2-network-3.4.12-3.6.4</FullProductName>
    </Branch>
    <Relationship ProductReference="apparmor-parser-2.8.2-56.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:apparmor-parser-2.8.2-56.15.1">apparmor-parser-2.8.2-56.15.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="bind-utils-9.11.22-3.57.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:bind-utils-9.11.22-3.57.1">bind-utils-9.11.22-3.57.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ca-certificates-mozilla-2.68-12.46.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:ca-certificates-mozilla-2.68-12.46.1">ca-certificates-mozilla-2.68-12.46.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="catatonit-0.1.3-1.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:catatonit-0.1.3-1.8.1">catatonit-0.1.3-1.8.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-10.3.7-52.117.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:cloud-regionsrv-client-10.3.7-52.117.1">cloud-regionsrv-client-10.3.7-52.117.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-plugin-gce-1.0.0-52.117.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:cloud-regionsrv-client-plugin-gce-1.0.0-52.117.1">cloud-regionsrv-client-plugin-gce-1.0.0-52.117.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="containerd-1.7.23-16.97.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:containerd-1.7.23-16.97.1">containerd-1.7.23-16.97.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="curl-8.0.1-11.101.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:curl-8.0.1-11.101.1">curl-8.0.1-11.101.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="docker-26.1.5_ce-98.120.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:docker-26.1.5_ce-98.120.1">docker-26.1.5_ce-98.120.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="expat-2.1.0-21.40.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:expat-2.1.0-21.40.1">expat-2.1.0-21.40.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glib2-tools-2.48.2-12.43.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:glib2-tools-2.48.2-12.43.1">glib2-tools-2.48.2-12.43.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-agent-20241011.01-1.41.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:google-guest-agent-20241011.01-1.41.3">google-guest-agent-20241011.01-1.41.3 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-configs-20241121.00-1.35.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:google-guest-configs-20241121.00-1.35.1">google-guest-configs-20241121.00-1.35.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-osconfig-agent-20240926.03-1.29.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:google-osconfig-agent-20240926.03-1.29.3">google-osconfig-agent-20240926.03-1.29.3 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grep-2.16-4.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:grep-2.16-4.9.1">grep-2.16-4.9.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-2.02-175.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:grub2-2.02-175.1">grub2-2.02-175.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-i386-pc-2.02-175.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:grub2-i386-pc-2.02-175.1">grub2-i386-pc-2.02-175.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="grub2-x86_64-efi-2.02-175.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:grub2-x86_64-efi-2.02-175.1">grub2-x86_64-efi-2.02-175.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="iputils-s20161105-11.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:iputils-s20161105-11.6.2">iputils-s20161105-11.6.2 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kernel-default-4.12.14-122.237.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1">kernel-default-4.12.14-122.237.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ksh-93vu-19.3.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:ksh-93vu-19.3.2">ksh-93vu-19.3.2 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libapparmor1-2.8.2-56.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libapparmor1-2.8.2-56.15.1">libapparmor1-2.8.2-56.15.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libavahi-client3-0.6.32-32.30.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libavahi-client3-0.6.32-32.30.1">libavahi-client3-0.6.32-32.30.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libavahi-common3-0.6.32-32.30.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libavahi-common3-0.6.32-32.30.1">libavahi-common3-0.6.32-32.30.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libbind9-161-9.11.22-3.57.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libbind9-161-9.11.22-3.57.1">libbind9-161-9.11.22-3.57.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libblkid1-2.33.2-4.45.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libblkid1-2.33.2-4.45.2">libblkid1-2.33.2-4.45.2 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcurl4-8.0.1-11.101.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libcurl4-8.0.1-11.101.1">libcurl4-8.0.1-11.101.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libdns1110-9.11.22-3.57.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libdns1110-9.11.22-3.57.1">libdns1110-9.11.22-3.57.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libexpat1-2.1.0-21.40.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libexpat1-2.1.0-21.40.1">libexpat1-2.1.0-21.40.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfdisk1-2.33.2-4.45.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libfdisk1-2.33.2-4.45.2">libfdisk1-2.33.2-4.45.2 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgcc_s1-13.3.0+git8781-1.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libgcc_s1-13.3.0+git8781-1.16.1">libgcc_s1-13.3.0+git8781-1.16.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgio-2_0-0-2.48.2-12.43.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libgio-2_0-0-2.48.2-12.43.1">libgio-2_0-0-2.48.2-12.43.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libglib-2_0-0-2.48.2-12.43.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libglib-2_0-0-2.48.2-12.43.1">libglib-2_0-0-2.48.2-12.43.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgmodule-2_0-0-2.48.2-12.43.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libgmodule-2_0-0-2.48.2-12.43.1">libgmodule-2_0-0-2.48.2-12.43.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgobject-2_0-0-2.48.2-12.43.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libgobject-2_0-0-2.48.2-12.43.1">libgobject-2_0-0-2.48.2-12.43.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libirs161-9.11.22-3.57.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libirs161-9.11.22-3.57.1">libirs161-9.11.22-3.57.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libisc1107-9.11.22-3.57.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libisc1107-9.11.22-3.57.1">libisc1107-9.11.22-3.57.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libisccc161-9.11.22-3.57.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libisccc161-9.11.22-3.57.1">libisccc161-9.11.22-3.57.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libisccfg163-9.11.22-3.57.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libisccfg163-9.11.22-3.57.1">libisccfg163-9.11.22-3.57.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="liblwres161-9.11.22-3.57.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:liblwres161-9.11.22-3.57.1">liblwres161-9.11.22-3.57.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libmount1-2.33.2-4.45.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libmount1-2.33.2-4.45.2">libmount1-2.33.2-4.45.2 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libopenssl1_0_0-1.0.2p-3.95.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libopenssl1_0_0-1.0.2p-3.95.1">libopenssl1_0_0-1.0.2p-3.95.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libopenssl1_1-1.1.1d-2.113.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libopenssl1_1-1.1.1d-2.113.1">libopenssl1_1-1.1.1d-2.113.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpcap1-1.8.1-10.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libpcap1-1.8.1-10.6.1">libpcap1-1.8.1-10.6.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython2_7-1_0-2.7.18-33.38.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libpython2_7-1_0-2.7.18-33.38.1">libpython2_7-1_0-2.7.18-33.38.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython3_4m1_0-3.4.10-25.145.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libpython3_4m1_0-3.4.10-25.145.1">libpython3_4m1_0-3.4.10-25.145.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython3_6m1_0-3.6.15-73.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libpython3_6m1_0-3.6.15-73.1">libpython3_6m1_0-3.6.15-73.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libruby2_1-2_1-2.1.9-19.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libruby2_1-2_1-2.1.9-19.9.1">libruby2_1-2_1-2.1.9-19.9.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsmartcols1-2.33.2-4.45.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libsmartcols1-2.33.2-4.45.2">libsmartcols1-2.33.2-4.45.2 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libstdc++6-13.3.0+git8781-1.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libstdc++6-13.3.0+git8781-1.16.1">libstdc++6-13.3.0+git8781-1.16.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsuseconnect-1.13.0-3.28.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libsuseconnect-1.13.0-3.28.1">libsuseconnect-1.13.0-3.28.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsystemd0-228-157.63.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libsystemd0-228-157.63.1">libsystemd0-228-157.63.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libudev1-228-157.63.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libudev1-228-157.63.1">libudev1-228-157.63.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libuuid1-2.33.2-4.45.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libuuid1-2.33.2-4.45.2">libuuid1-2.33.2-4.45.2 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libzypp-16.22.15-72.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libzypp-16.22.15-72.1">libzypp-16.22.15-72.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nss-certs-3.101.2-58.124.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:mozilla-nss-certs-3.101.2-58.124.1">mozilla-nss-certs-3.101.2-58.124.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssl-1_0_0-1.0.2p-3.95.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:openssl-1_0_0-1.0.2p-3.95.1">openssl-1_0_0-1.0.2p-3.95.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pam-1.1.8-24.59.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:pam-1.1.8-24.59.1">pam-1.1.8-24.59.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python-2.7.18-33.38.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python-2.7.18-33.38.1">python-2.7.18-33.38.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python-base-2.7.18-33.38.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python-base-2.7.18-33.38.1">python-base-2.7.18-33.38.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python-bind-9.11.22-3.57.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python-bind-9.11.22-3.57.1">python-bind-9.11.22-3.57.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python-xml-2.7.18-33.38.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python-xml-2.7.18-33.38.1">python-xml-2.7.18-33.38.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-3.4.10-25.145.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-3.4.10-25.145.1">python3-3.4.10-25.145.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-base-3.4.10-25.145.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-base-3.4.10-25.145.1">python3-base-3.4.10-25.145.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-pyOpenSSL-17.1.0-4.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-pyOpenSSL-17.1.0-4.29.1">python3-pyOpenSSL-17.1.0-4.29.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-setuptools-40.6.2-4.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-setuptools-40.6.2-4.24.1">python3-setuptools-40.6.2-4.24.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-urllib3-1.25.10-3.40.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-urllib3-1.25.10-3.40.1">python3-urllib3-1.25.10-3.40.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python36-base-3.6.15-73.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python36-base-3.6.15-73.1">python36-base-3.6.15-73.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="regionServiceClientConfigGCE-4.2.0-5.18.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:regionServiceClientConfigGCE-4.2.0-5.18.1">regionServiceClientConfigGCE-4.2.0-5.18.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="release-notes-sles-12.5.20241206-3.43.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:release-notes-sles-12.5.20241206-3.43.3">release-notes-sles-12.5.20241206-3.43.3 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby2.1-2.1.9-19.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:ruby2.1-2.1.9-19.9.1">ruby2.1-2.1.9-19.9.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby2.1-stdlib-2.1.9-19.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:ruby2.1-stdlib-2.1.9-19.9.1">ruby2.1-stdlib-2.1.9-19.9.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="runc-1.1.14-16.57.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:runc-1.1.14-16.57.1">runc-1.1.14-16.57.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="shadow-4.2.1-36.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:shadow-4.2.1-36.15.1">shadow-4.2.1-36.15.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="sles-release-12.5-9.5.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:sles-release-12.5-9.5.2">sles-release-12.5-9.5.2 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="sles-release-POOL-12.5-9.5.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:sles-release-POOL-12.5-9.5.2">sles-release-POOL-12.5-9.5.2 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="sudo-1.8.27-4.51.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:sudo-1.8.27-4.51.1">sudo-1.8.27-4.51.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suse-build-key-12.0-7.19.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:suse-build-key-12.0-7.19.1">suse-build-key-12.0-7.19.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ng-1.13.0-3.28.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:suseconnect-ng-1.13.0-3.28.1">suseconnect-ng-1.13.0-3.28.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ruby-bindings-1.13.0-3.28.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:suseconnect-ruby-bindings-1.13.0-3.28.1">suseconnect-ruby-bindings-1.13.0-3.28.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-228-157.63.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:systemd-228-157.63.1">systemd-228-157.63.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-sysvinit-228-157.63.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:systemd-sysvinit-228-157.63.1">systemd-sysvinit-228-157.63.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="udev-228-157.63.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:udev-228-157.63.1">udev-228-157.63.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-2.33.2-4.45.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:util-linux-2.33.2-4.45.2">util-linux-2.33.2-4.45.2 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-systemd-2.33.2-4.45.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:util-linux-systemd-2.33.2-4.45.2">util-linux-systemd-2.33.2-4.45.2 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-9.1.0836-17.38.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:vim-9.1.0836-17.38.1">vim-9.1.0836-17.38.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-data-common-9.1.0836-17.38.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:vim-data-common-9.1.0836-17.38.1">vim-data-common-9.1.0836-17.38.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wicked-0.6.77-3.53.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:wicked-0.6.77-3.53.1">wicked-0.6.77-3.53.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wicked-service-0.6.77-3.53.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:wicked-service-0.6.77-3.53.1">wicked-service-0.6.77-3.53.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="xfsprogs-4.15.0-3.28.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:xfsprogs-4.15.0-3.28.1">xfsprogs-4.15.0-3.28.1 as a component of Public Cloud Image google/sles-12-sp5-v20250103-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-network-3.4.12-3.6.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-v20250103-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-v20250103-x86-64:yast2-network-3.4.12-3.6.4">yast2-network-3.4.12-3.6.4 as a component of Public Cloud Image google/sles-12-sp5-v20250103-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">shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees</Note>
    </Notes>
    <CVE>CVE-2013-4235</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:shadow-4.2.1-36.15.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>3.3</BaseScore>
        <Vector>AV:L/AC:M/Au:N/C:N/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">Python Cryptographic Authority pyopenssl version prior to version 17.5.0 contains a CWE-416: Use After Free vulnerability in X509 object handling that can result in Use after free can lead to possible denial of service or remote code execution.. This attack appear to be exploitable via Depends on the calling application and if it retains a reference to the memory.. This vulnerability appears to have been fixed in 17.5.0.</Note>
    </Notes>
    <CVE>CVE-2018-1000807</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-pyOpenSSL-17.1.0-4.29.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>6.8</BaseScore>
        <Vector>AV:N/AC:M/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 ksh version 20120801, a flaw was found in the way it evaluates certain environment variables. An attacker could use this flaw to override or bypass environment restrictions to execute shell commands. Services and applications that allow remote unauthenticated attackers to provide one of those environment variables could allow them to exploit this issue remotely.</Note>
    </Notes>
    <CVE>CVE-2019-14868</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>7.2</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:C/I:C/A:C</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">Bluetooth LE and BR/EDR secure pairing in Bluetooth Core Specification 2.1 through 5.2 may permit a nearby man-in-the-middle attacker to identify the Passkey used during pairing (in the Passkey authentication procedure) by reflection of the public key and the authentication evidence of the initiating device, potentially permitting this attacker to complete authenticated pairing with the responding device using the correct Passkey for the pairing session. The attack methodology determines the Passkey value one bit at a time.</Note>
    </Notes>
    <CVE>CVE-2020-26558</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>4.3</BaseScore>
        <Vector>AV:A/AC:M/Au:N/C:P/I:P/A:N</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Improper access control in BlueZ may allow an authenticated user to potentially enable information disclosure via adjacent access.</Note>
    </Notes>
    <CVE>CVE-2021-0129</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>2.7</BaseScore>
        <Vector>AV:A/AC:L/Au:S/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">Sudo before 1.9.5p2 contains an off-by-one error that can result in a heap-based buffer overflow, which allows privilege escalation to root via "sudoedit -s" and a command-line argument that ends with a single backslash character.</Note>
    </Notes>
    <CVE>CVE-2021-3156</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:sudo-1.8.27-4.51.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>7.2</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:C/I:C/A:C</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:

x86/xen: Drop USERGS_SYSRET64 paravirt call

commit afd30525a659ac0ae0904f0cb4a2ca75522c3123 upstream.

USERGS_SYSRET64 is used to return from a syscall via SYSRET, but
a Xen PV guest will nevertheless use the IRET hypercall, as there
is no sysret PV hypercall defined.

So instead of testing all the prerequisites for doing a sysret and
then mangling the stack for Xen PV again for doing an iret just use
the iret exit from the beginning.

This can easily be done via an ALTERNATIVE like it is done for the
sysenter compat case already.

It should be noted that this drops the optimization in Xen for not
restoring a few registers when returning to user mode, but it seems
as if the saved instructions in the kernel more than compensate for
this drop (a kernel build in a Xen PV guest was slightly faster with
this patch applied).

While at it remove the stale sysret32 remnants.

  [ pawan: Brad Spengler and Salvatore Bonaccorso &lt;carnil@debian.org&gt;
	   reported a problem with the 5.10 backport commit edc702b4a820
	   ("x86/entry_64: Add VERW just before userspace transition").

	   When CONFIG_PARAVIRT_XXL=y, CLEAR_CPU_BUFFERS is not executed in
	   syscall_return_via_sysret path as USERGS_SYSRET64 is runtime
	   patched to:

	.cpu_usergs_sysret64    = { 0x0f, 0x01, 0xf8,
				    0x48, 0x0f, 0x07 }, // swapgs; sysretq

	   which is missing CLEAR_CPU_BUFFERS. It turns out dropping
	   USERGS_SYSRET64 simplifies the code, allowing CLEAR_CPU_BUFFERS
	   to be explicitly added to syscall_return_via_sysret path. Below
	   is with CONFIG_PARAVIRT_XXL=y and this patch applied:

	   syscall_return_via_sysret:
	   ...
	   &lt;+342&gt;:   swapgs
	   &lt;+345&gt;:   xchg   %ax,%ax
	   &lt;+347&gt;:   verw   -0x1a2(%rip)  &lt;------
	   &lt;+354&gt;:   sysretq
  ]</Note>
    </Notes>
    <CVE>CVE-2021-4440</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: fix use-after-free in tw_timer_handler

A real world panic issue was found as follow in Linux 5.4.

    BUG: unable to handle page fault for address: ffffde49a863de28
    PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0
    RIP: 0010:tw_timer_handler+0x20/0x40
    Call Trace:
     &lt;IRQ&gt;
     call_timer_fn+0x2b/0x120
     run_timer_softirq+0x1ef/0x450
     __do_softirq+0x10d/0x2b8
     irq_exit+0xc7/0xd0
     smp_apic_timer_interrupt+0x68/0x120
     apic_timer_interrupt+0xf/0x20

This issue was also reported since 2017 in the thread [1],
unfortunately, the issue was still can be reproduced after fixing
DCCP.

The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a net
namespace is destroyed since tcp_sk_ops is registered befrore
ipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_ops
in the list of pernet_list. There will be a use-after-free on
net-&gt;mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net
if there are some inflight time-wait timers.

This bug is not introduced by commit f2bf415cfed7 ("mib: add net to
NET_ADD_STATS_BH") since the net_statistics is a global variable
instead of dynamic allocation and freeing. Actually, commit
61a7e26028b9 ("mib: put net statistics on struct net") introduces
the bug since it put net statistics on struct net and free it when
net namespace is destroyed.

Moving init_ipv4_mibs() to the front of tcp_init() to fix this bug
and replace pr_crit() with panic() since continuing is meaningless
when init_ipv4_mibs() fails.

[1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1</Note>
    </Notes>
    <CVE>CVE-2021-46936</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tipc: skb_linearize the head skb when reassembling msgs

It's not a good idea to append the frag skb to a skb's frag_list if
the frag_list already has skbs from elsewhere, such as this skb was
created by pskb_copy() where the frag_list was cloned (all the skbs
in it were skb_get'ed) and shared by multiple skbs.

However, the new appended frag skb should have been only seen by the
current skb. Otherwise, it will cause use after free crashes as this
appended frag skb are seen by multiple skbs but it only got skb_get
called once.

The same thing happens with a skb updated by pskb_may_pull() with a
skb_cloned skb. Li Shuang has reported quite a few crashes caused
by this when doing testing over macvlan devices:

  [] kernel BUG at net/core/skbuff.c:1970!
  [] Call Trace:
  []  skb_clone+0x4d/0xb0
  []  macvlan_broadcast+0xd8/0x160 [macvlan]
  []  macvlan_process_broadcast+0x148/0x150 [macvlan]
  []  process_one_work+0x1a7/0x360
  []  worker_thread+0x30/0x390

  [] kernel BUG at mm/usercopy.c:102!
  [] Call Trace:
  []  __check_heap_object+0xd3/0x100
  []  __check_object_size+0xff/0x16b
  []  simple_copy_to_iter+0x1c/0x30
  []  __skb_datagram_iter+0x7d/0x310
  []  __skb_datagram_iter+0x2a5/0x310
  []  skb_copy_datagram_iter+0x3b/0x90
  []  tipc_recvmsg+0x14a/0x3a0 [tipc]
  []  ____sys_recvmsg+0x91/0x150
  []  ___sys_recvmsg+0x7b/0xc0

  [] kernel BUG at mm/slub.c:305!
  [] Call Trace:
  []  &lt;IRQ&gt;
  []  kmem_cache_free+0x3ff/0x400
  []  __netif_receive_skb_core+0x12c/0xc40
  []  ? kmem_cache_alloc+0x12e/0x270
  []  netif_receive_skb_internal+0x3d/0xb0
  []  ? get_rx_page_info+0x8e/0xa0 [be2net]
  []  be_poll+0x6ef/0xd00 [be2net]
  []  ? irq_exit+0x4f/0x100
  []  net_rx_action+0x149/0x3b0

  ...

This patch is to fix it by linearizing the head skb if it has frag_list
set in tipc_buf_append(). Note that we choose to do this before calling
skb_unshare(), as __skb_linearize() will avoid skb_copy(). Also, we can
not just drop the frag_list either as the early time.</Note>
    </Notes>
    <CVE>CVE-2021-47162</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tipc: wait and exit until all work queues are done

On some host, a crash could be triggered simply by repeating these
commands several times:

  # modprobe tipc
  # tipc bearer enable media udp name UDP1 localip 127.0.0.1
  # rmmod tipc

  [] BUG: unable to handle kernel paging request at ffffffffc096bb00
  [] Workqueue: events 0xffffffffc096bb00
  [] Call Trace:
  []  ? process_one_work+0x1a7/0x360
  []  ? worker_thread+0x30/0x390
  []  ? create_worker+0x1a0/0x1a0
  []  ? kthread+0x116/0x130
  []  ? kthread_flush_work_fn+0x10/0x10
  []  ? ret_from_fork+0x35/0x40

When removing the TIPC module, the UDP tunnel sock will be delayed to
release in a work queue as sock_release() can't be done in rtnl_lock().
If the work queue is schedule to run after the TIPC module is removed,
kernel will crash as the work queue function cleanup_beareri() code no
longer exists when trying to invoke it.

To fix it, this patch introduce a member wq_count in tipc_net to track
the numbers of work queues in schedule, and  wait and exit until all
work queues are done in tipc_exit_net().</Note>
    </Notes>
    <CVE>CVE-2021-47163</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: ieee802154: fix null deref in parse dev addr

Fix a logic error that could result in a null deref if the user sets
the mode incorrectly for the given addr type.</Note>
    </Notes>
    <CVE>CVE-2021-47257</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 memory leak in tcindex_partial_destroy_work

Syzbot reported memory leak in tcindex_set_parms(). The problem was in
non-freed perfect hash in tcindex_partial_destroy_work().

In tcindex_set_parms() new tcindex_data is allocated and some fields from
old one are copied to new one, but not the perfect hash. Since
tcindex_partial_destroy_work() is the destroy function for old
tcindex_data, we need to free perfect hash to avoid memory leak.</Note>
    </Notes>
    <CVE>CVE-2021-47295</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: mmio: Fix use-after-free Read in kvm_vm_ioctl_unregister_coalesced_mmio

BUG: KASAN: use-after-free in kvm_vm_ioctl_unregister_coalesced_mmio+0x7c/0x1ec arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:183
Read of size 8 at addr ffff0000c03a2500 by task syz-executor083/4269

CPU: 5 PID: 4269 Comm: syz-executor083 Not tainted 5.10.0 #7
Hardware name: linux,dummy-virt (DT)
Call trace:
 dump_backtrace+0x0/0x2d0 arch/arm64/kernel/stacktrace.c:132
 show_stack+0x28/0x34 arch/arm64/kernel/stacktrace.c:196
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x110/0x164 lib/dump_stack.c:118
 print_address_description+0x78/0x5c8 mm/kasan/report.c:385
 __kasan_report mm/kasan/report.c:545 [inline]
 kasan_report+0x148/0x1e4 mm/kasan/report.c:562
 check_memory_region_inline mm/kasan/generic.c:183 [inline]
 __asan_load8+0xb4/0xbc mm/kasan/generic.c:252
 kvm_vm_ioctl_unregister_coalesced_mmio+0x7c/0x1ec arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:183
 kvm_vm_ioctl+0xe30/0x14c4 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3755
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl fs/ioctl.c:739 [inline]
 __arm64_sys_ioctl+0xf88/0x131c fs/ioctl.c:739
 __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
 invoke_syscall arch/arm64/kernel/syscall.c:48 [inline]
 el0_svc_common arch/arm64/kernel/syscall.c:158 [inline]
 do_el0_svc+0x120/0x290 arch/arm64/kernel/syscall.c:220
 el0_svc+0x1c/0x28 arch/arm64/kernel/entry-common.c:367
 el0_sync_handler+0x98/0x170 arch/arm64/kernel/entry-common.c:383
 el0_sync+0x140/0x180 arch/arm64/kernel/entry.S:670

Allocated by task 4269:
 stack_trace_save+0x80/0xb8 kernel/stacktrace.c:121
 kasan_save_stack mm/kasan/common.c:48 [inline]
 kasan_set_track mm/kasan/common.c:56 [inline]
 __kasan_kmalloc+0xdc/0x120 mm/kasan/common.c:461
 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:475
 kmem_cache_alloc_trace include/linux/slab.h:450 [inline]
 kmalloc include/linux/slab.h:552 [inline]
 kzalloc include/linux/slab.h:664 [inline]
 kvm_vm_ioctl_register_coalesced_mmio+0x78/0x1cc arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:146
 kvm_vm_ioctl+0x7e8/0x14c4 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3746
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl fs/ioctl.c:739 [inline]
 __arm64_sys_ioctl+0xf88/0x131c fs/ioctl.c:739
 __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
 invoke_syscall arch/arm64/kernel/syscall.c:48 [inline]
 el0_svc_common arch/arm64/kernel/syscall.c:158 [inline]
 do_el0_svc+0x120/0x290 arch/arm64/kernel/syscall.c:220
 el0_svc+0x1c/0x28 arch/arm64/kernel/entry-common.c:367
 el0_sync_handler+0x98/0x170 arch/arm64/kernel/entry-common.c:383
 el0_sync+0x140/0x180 arch/arm64/kernel/entry.S:670

Freed by task 4269:
 stack_trace_save+0x80/0xb8 kernel/stacktrace.c:121
 kasan_save_stack mm/kasan/common.c:48 [inline]
 kasan_set_track+0x38/0x6c mm/kasan/common.c:56
 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:355
 __kasan_slab_free+0x124/0x150 mm/kasan/common.c:422
 kasan_slab_free+0x10/0x1c mm/kasan/common.c:431
 slab_free_hook mm/slub.c:1544 [inline]
 slab_free_freelist_hook mm/slub.c:1577 [inline]
 slab_free mm/slub.c:3142 [inline]
 kfree+0x104/0x38c mm/slub.c:4124
 coalesced_mmio_destructor+0x94/0xa4 arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:102
 kvm_iodevice_destructor include/kvm/iodev.h:61 [inline]
 kvm_io_bus_unregister_dev+0x248/0x280 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:4374
 kvm_vm_ioctl_unregister_coalesced_mmio+0x158/0x1ec arch/arm64/kvm/../../../virt/kvm/coalesced_mmio.c:186
 kvm_vm_ioctl+0xe30/0x14c4 arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3755
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl fs/ioctl.c:739 [inline]
 __arm64_sys_ioctl+0xf88/0x131c fs/ioctl.c:739
 __invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
 invoke_syscall arch/arm64/kernel/sys
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47341</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

irqchip/gic-v3-its: Fix potential VPE leak on error

In its_vpe_irq_domain_alloc, when its_vpe_init() returns an error,
there is an off-by-one in the number of VPEs to be freed.

Fix it by simply passing the number of VPEs allocated, which is the
index of the loop iterating over the VPEs.

[maz: fixed commit message]</Note>
    </Notes>
    <CVE>CVE-2021-47373</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

cpufreq: schedutil: Use kobject release() method to free sugov_tunables

The struct sugov_tunables is protected by the kobject, so we can't free
it directly. Otherwise we would get a call trace like this:
  ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x30
  WARNING: CPU: 3 PID: 720 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100
  Modules linked in:
  CPU: 3 PID: 720 Comm: a.sh Tainted: G        W         5.14.0-rc1-next-20210715-yocto-standard+ #507
  Hardware name: Marvell OcteonTX CN96XX board (DT)
  pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--)
  pc : debug_print_object+0xb8/0x100
  lr : debug_print_object+0xb8/0x100
  sp : ffff80001ecaf910
  x29: ffff80001ecaf910 x28: ffff00011b10b8d0 x27: ffff800011043d80
  x26: ffff00011a8f0000 x25: ffff800013cb3ff0 x24: 0000000000000000
  x23: ffff80001142aa68 x22: ffff800011043d80 x21: ffff00010de46f20
  x20: ffff800013c0c520 x19: ffff800011d8f5b0 x18: 0000000000000010
  x17: 6e6968207473696c x16: 5f72656d6974203a x15: 6570797420746365
  x14: 6a626f2029302065 x13: 303378302f307830 x12: 2b6e665f72656d69
  x11: ffff8000124b1560 x10: ffff800012331520 x9 : ffff8000100ca6b0
  x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 0000000000000001
  x5 : ffff800011d8c000 x4 : ffff800011d8c740 x3 : 0000000000000000
  x2 : ffff0001108301c0 x1 : ab3c90eedf9c0f00 x0 : 0000000000000000
  Call trace:
   debug_print_object+0xb8/0x100
   __debug_check_no_obj_freed+0x1c0/0x230
   debug_check_no_obj_freed+0x20/0x88
   slab_free_freelist_hook+0x154/0x1c8
   kfree+0x114/0x5d0
   sugov_exit+0xbc/0xc0
   cpufreq_exit_governor+0x44/0x90
   cpufreq_set_policy+0x268/0x4a8
   store_scaling_governor+0xe0/0x128
   store+0xc0/0xf0
   sysfs_kf_write+0x54/0x80
   kernfs_fop_write_iter+0x128/0x1c0
   new_sync_write+0xf0/0x190
   vfs_write+0x2d4/0x478
   ksys_write+0x74/0x100
   __arm64_sys_write+0x24/0x30
   invoke_syscall.constprop.0+0x54/0xe0
   do_el0_svc+0x64/0x158
   el0_svc+0x2c/0xb0
   el0t_64_sync_handler+0xb0/0xb8
   el0t_64_sync+0x198/0x19c
  irq event stamp: 5518
  hardirqs last  enabled at (5517): [&lt;ffff8000100cbd7c&gt;] console_unlock+0x554/0x6c8
  hardirqs last disabled at (5518): [&lt;ffff800010fc0638&gt;] el1_dbg+0x28/0xa0
  softirqs last  enabled at (5504): [&lt;ffff8000100106e0&gt;] __do_softirq+0x4d0/0x6c0
  softirqs last disabled at (5483): [&lt;ffff800010049548&gt;] irq_exit+0x1b0/0x1b8

So split the original sugov_tunables_free() into two functions,
sugov_clear_global_tunables() is just used to clear the global_tunables
and the new sugov_tunables_free() is used as kobj_type::release to
release the sugov_tunables safely.</Note>
    </Notes>
    <CVE>CVE-2021-47387</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mac80211: fix use-after-free in CCMP/GCMP RX

When PN checking is done in mac80211, for fragmentation we need
to copy the PN to the RX struct so we can later use it to do a
comparison, since commit bf30ca922a0c ("mac80211: check defrag
PN against current frame").

Unfortunately, in that commit I used the 'hdr' variable without
it being necessarily valid, so use-after-free could occur if it
was necessary to reallocate (parts of) the frame.

Fix this by reloading the variable after the code that results
in the reallocations, if any.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=214401.</Note>
    </Notes>
    <CVE>CVE-2021-47388</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mac80211: limit injected vht mcs/nss in ieee80211_parse_tx_radiotap

Limit max values for vht mcs and nss in ieee80211_parse_tx_radiotap
routine in order to fix the following warning reported by syzbot:

WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]
WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244
Modules linked in:
CPU: 0 PID: 10717 Comm: syz-executor.5 Not tainted 5.14.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]
RIP: 0010:ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244
RSP: 0018:ffffc9000186f3e8 EFLAGS: 00010216
RAX: 0000000000000618 RBX: ffff88804ef76500 RCX: ffffc900143a5000
RDX: 0000000000040000 RSI: ffffffff888f478e RDI: 0000000000000003
RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000100
R10: ffffffff888f46f9 R11: 0000000000000000 R12: 00000000fffffff8
R13: ffff88804ef7653c R14: 0000000000000001 R15: 0000000000000004
FS:  00007fbf5718f700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2de23000 CR3: 000000006a671000 CR4: 00000000001506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
Call Trace:
 ieee80211_monitor_select_queue+0xa6/0x250 net/mac80211/iface.c:740
 netdev_core_pick_tx+0x169/0x2e0 net/core/dev.c:4089
 __dev_queue_xmit+0x6f9/0x3710 net/core/dev.c:4165
 __bpf_tx_skb net/core/filter.c:2114 [inline]
 __bpf_redirect_no_mac net/core/filter.c:2139 [inline]
 __bpf_redirect+0x5ba/0xd20 net/core/filter.c:2162
 ____bpf_clone_redirect net/core/filter.c:2429 [inline]
 bpf_clone_redirect+0x2ae/0x420 net/core/filter.c:2401
 bpf_prog_eeb6f53a69e5c6a2+0x59/0x234
 bpf_dispatcher_nop_func include/linux/bpf.h:717 [inline]
 __bpf_prog_run include/linux/filter.h:624 [inline]
 bpf_prog_run include/linux/filter.h:631 [inline]
 bpf_test_run+0x381/0xa30 net/bpf/test_run.c:119
 bpf_prog_test_run_skb+0xb84/0x1ee0 net/bpf/test_run.c:663
 bpf_prog_test_run kernel/bpf/syscall.c:3307 [inline]
 __sys_bpf+0x2137/0x5df0 kernel/bpf/syscall.c:4605
 __do_sys_bpf kernel/bpf/syscall.c:4691 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:4689 [inline]
 __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x4665f9</Note>
    </Notes>
    <CVE>CVE-2021-47395</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ixgbe: Fix NULL pointer dereference in ixgbe_xdp_setup

The ixgbe driver currently generates a NULL pointer dereference with
some machine (online cpus &lt; 63). This is due to the fact that the
maximum value of num_xdp_queues is nr_cpu_ids. Code is in
"ixgbe_set_rss_queues"".

Here's how the problem repeats itself:
Some machine (online cpus &lt; 63), And user set num_queues to 63 through
ethtool. Code is in the "ixgbe_set_channels",
	adapter-&gt;ring_feature[RING_F_FDIR].limit = count;

It becomes 63.

When user use xdp, "ixgbe_set_rss_queues" will set queues num.
	adapter-&gt;num_rx_queues = rss_i;
	adapter-&gt;num_tx_queues = rss_i;
	adapter-&gt;num_xdp_queues = ixgbe_xdp_queues(adapter);

And rss_i's value is from
	f = &amp;adapter-&gt;ring_feature[RING_F_FDIR];
	rss_i = f-&gt;indices = f-&gt;limit;

So "num_rx_queues" &gt; "num_xdp_queues", when run to "ixgbe_xdp_setup",
	for (i = 0; i &lt; adapter-&gt;num_rx_queues; i++)
		if (adapter-&gt;xdp_ring[i]-&gt;xsk_umem)

It leads to panic.

Call trace:
[exception RIP: ixgbe_xdp+368]
RIP: ffffffffc02a76a0  RSP: ffff9fe16202f8d0  RFLAGS: 00010297
RAX: 0000000000000000  RBX: 0000000000000020  RCX: 0000000000000000
RDX: 0000000000000000  RSI: 000000000000001c  RDI: ffffffffa94ead90
RBP: ffff92f8f24c0c18   R8: 0000000000000000   R9: 0000000000000000
R10: ffff9fe16202f830  R11: 0000000000000000  R12: ffff92f8f24c0000
R13: ffff9fe16202fc01  R14: 000000000000000a  R15: ffffffffc02a7530
ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 7 [ffff9fe16202f8f0] dev_xdp_install at ffffffffa89fbbcc
 8 [ffff9fe16202f920] dev_change_xdp_fd at ffffffffa8a08808
 9 [ffff9fe16202f960] do_setlink at ffffffffa8a20235
10 [ffff9fe16202fa88] rtnl_setlink at ffffffffa8a20384
11 [ffff9fe16202fc78] rtnetlink_rcv_msg at ffffffffa8a1a8dd
12 [ffff9fe16202fcf0] netlink_rcv_skb at ffffffffa8a717eb
13 [ffff9fe16202fd40] netlink_unicast at ffffffffa8a70f88
14 [ffff9fe16202fd80] netlink_sendmsg at ffffffffa8a71319
15 [ffff9fe16202fdf0] sock_sendmsg at ffffffffa89df290
16 [ffff9fe16202fe08] __sys_sendto at ffffffffa89e19c8
17 [ffff9fe16202ff30] __x64_sys_sendto at ffffffffa89e1a64
18 [ffff9fe16202ff38] do_syscall_64 at ffffffffa84042b9
19 [ffff9fe16202ff50] entry_SYSCALL_64_after_hwframe at ffffffffa8c0008c

So I fix ixgbe_max_channels so that it will not allow a setting of queues
to be higher than the num_online_cpus(). And when run to ixgbe_xdp_setup,
take the smaller value of num_rx_queues and num_xdp_queues.</Note>
    </Notes>
    <CVE>CVE-2021-47399</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipack: ipoctal: fix module reference leak

A reference to the carrier module was taken on every open but was only
released once when the final reference to the tty struct was dropped.

Fix this by taking the module reference and initialising the tty driver
data when installing the tty.</Note>
    </Notes>
    <CVE>CVE-2021-47403</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

HID: usbhid: free raw_report buffers in usbhid_stop

Free the unsent raw_report buffers when the device is removed.

Fixes a memory leak reported by syzbot at:
https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47</Note>
    </Notes>
    <CVE>CVE-2021-47405</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

phy: mdio: fix memory leak

Syzbot reported memory leak in MDIO bus interface, the problem was in
wrong state logic.

MDIOBUS_ALLOCATED indicates 2 states:
	1. Bus is only allocated
	2. Bus allocated and __mdiobus_register() fails, but
	   device_register() was called

In case of device_register() has been called we should call put_device()
to correctly free the memory allocated for this device, but mdiobus_free()
calls just kfree(dev) in case of MDIOBUS_ALLOCATED state

To avoid this behaviour we need to set bus-&gt;state to MDIOBUS_UNREGISTERED
_before_ calling device_register(), because put_device() should be
called even in case of device_register() failure.</Note>
    </Notes>
    <CVE>CVE-2021-47416</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

i2c: acpi: fix resource leak in reconfiguration device addition

acpi_i2c_find_adapter_by_handle() calls bus_find_device() which takes a
reference on the adapter which is never released which will result in a
reference count leak and render the adapter unremovable.  Make sure to
put the adapter after creating the client in the same manner that we do
for OF.

[wsa: fixed title]</Note>
    </Notes>
    <CVE>CVE-2021-47425</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path

Prior to this patch in case mlx5_core_destroy_cq() failed it returns
without completing all destroy operations and that leads to memory leak.
Instead, complete the destroy flow before return error.

Also move mlx5_debug_cq_remove() to the beginning of mlx5_core_destroy_cq()
to be symmetrical with mlx5_core_create_cq().

kmemleak complains on:

unreferenced object 0xc000000038625100 (size 64):
  comm "ethtool", pid 28301, jiffies 4298062946 (age 785.380s)
  hex dump (first 32 bytes):
    60 01 48 94 00 00 00 c0 b8 05 34 c3 00 00 00 c0  `.H.......4.....
    02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0  ..........}.....
  backtrace:
    [&lt;000000009e8643cb&gt;] add_res_tree+0xd0/0x270 [mlx5_core]
    [&lt;00000000e7cb8e6c&gt;] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core]
    [&lt;000000002a12918f&gt;] mlx5_core_create_cq+0x1d0/0x2d0 [mlx5_core]
    [&lt;00000000cef0a696&gt;] mlx5e_create_cq+0x210/0x3f0 [mlx5_core]
    [&lt;000000009c642c26&gt;] mlx5e_open_cq+0xb4/0x130 [mlx5_core]
    [&lt;0000000058dfa578&gt;] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core]
    [&lt;0000000081839561&gt;] mlx5e_open_channels+0x9cc/0x13e0 [mlx5_core]
    [&lt;0000000009cf05d4&gt;] mlx5e_switch_priv_channels+0xa4/0x230
[mlx5_core]
    [&lt;0000000042bbedd8&gt;] mlx5e_safe_switch_params+0x14c/0x300
[mlx5_core]
    [&lt;0000000004bc9db8&gt;] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core]
    [&lt;00000000a0553443&gt;] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core]
    [&lt;00000000a8f3d84b&gt;] ethnl_set_privflags+0x234/0x2d0
    [&lt;00000000fd27f27c&gt;] genl_family_rcv_msg_doit+0x108/0x1d0
    [&lt;00000000f495e2bb&gt;] genl_family_rcv_msg+0xe4/0x1f0
    [&lt;00000000646c5c2c&gt;] genl_rcv_msg+0x78/0x120
    [&lt;00000000d53e384e&gt;] netlink_rcv_skb+0x74/0x1a0</Note>
    </Notes>
    <CVE>CVE-2021-47438</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mlxsw: thermal: Fix out-of-bounds memory accesses

Currently, mlxsw allows cooling states to be set above the maximum
cooling state supported by the driver:

 # cat /sys/class/thermal/thermal_zone2/cdev0/type
 mlxsw_fan
 # cat /sys/class/thermal/thermal_zone2/cdev0/max_state
 10
 # echo 18 &gt; /sys/class/thermal/thermal_zone2/cdev0/cur_state
 # echo $?
 0

This results in out-of-bounds memory accesses when thermal state
transition statistics are enabled (CONFIG_THERMAL_STATISTICS=y), as the
transition table is accessed with a too large index (state) [1].

According to the thermal maintainer, it is the responsibility of the
driver to reject such operations [2].

Therefore, return an error when the state to be set exceeds the maximum
cooling state supported by the driver.

To avoid dead code, as suggested by the thermal maintainer [3],
partially revert commit a421ce088ac8 ("mlxsw: core: Extend cooling
device with cooling levels") that tried to interpret these invalid
cooling states (above the maximum) in a special way. The cooling levels
array is not removed in order to prevent the fans going below 20% PWM,
which would cause them to get stuck at 0% PWM.

[1]
BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x271/0x290
Read of size 4 at addr ffff8881052f7bf8 by task kworker/0:0/5

CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.15.0-rc3-custom-45935-gce1adf704b14 #122
Hardware name: Mellanox Technologies Ltd. "MSN2410-CB2FO"/"SA000874", BIOS 4.6.5 03/08/2016
Workqueue: events_freezable_power_ thermal_zone_device_check
Call Trace:
 dump_stack_lvl+0x8b/0xb3
 print_address_description.constprop.0+0x1f/0x140
 kasan_report.cold+0x7f/0x11b
 thermal_cooling_device_stats_update+0x271/0x290
 __thermal_cdev_update+0x15e/0x4e0
 thermal_cdev_update+0x9f/0xe0
 step_wise_throttle+0x770/0xee0
 thermal_zone_device_update+0x3f6/0xdf0
 process_one_work+0xa42/0x1770
 worker_thread+0x62f/0x13e0
 kthread+0x3ee/0x4e0
 ret_from_fork+0x1f/0x30

Allocated by task 1:
 kasan_save_stack+0x1b/0x40
 __kasan_kmalloc+0x7c/0x90
 thermal_cooling_device_setup_sysfs+0x153/0x2c0
 __thermal_cooling_device_register.part.0+0x25b/0x9c0
 thermal_cooling_device_register+0xb3/0x100
 mlxsw_thermal_init+0x5c5/0x7e0
 __mlxsw_core_bus_device_register+0xcb3/0x19c0
 mlxsw_core_bus_device_register+0x56/0xb0
 mlxsw_pci_probe+0x54f/0x710
 local_pci_probe+0xc6/0x170
 pci_device_probe+0x2b2/0x4d0
 really_probe+0x293/0xd10
 __driver_probe_device+0x2af/0x440
 driver_probe_device+0x51/0x1e0
 __driver_attach+0x21b/0x530
 bus_for_each_dev+0x14c/0x1d0
 bus_add_driver+0x3ac/0x650
 driver_register+0x241/0x3d0
 mlxsw_sp_module_init+0xa2/0x174
 do_one_initcall+0xee/0x5f0
 kernel_init_freeable+0x45a/0x4de
 kernel_init+0x1f/0x210
 ret_from_fork+0x1f/0x30

The buggy address belongs to the object at ffff8881052f7800
 which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 1016 bytes inside of
 1024-byte region [ffff8881052f7800, ffff8881052f7c00)
The buggy address belongs to the page:
page:0000000052355272 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1052f0
head:0000000052355272 order:3 compound_mapcount:0 compound_pincount:0
flags: 0x200000000010200(slab|head|node=0|zone=2)
raw: 0200000000010200 ffffea0005034800 0000000300000003 ffff888100041dc0
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff8881052f7a80: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc
 ffff8881052f7b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
&gt;ffff8881052f7b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                                ^
 ffff8881052f7c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff8881052f7c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

[2] https://lore.kernel.org/linux-pm/9aca37cb-1629-5c67-
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47441</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

isdn: mISDN: Fix sleeping function called from invalid context

The driver can call card-&gt;isac.release() function from an atomic
context.

Fix this by calling this function after releasing the lock.

The following log reveals it:

[   44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018
[   44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe
[   44.169574 ] INFO: lockdep is turned off.
[   44.169899 ] irq event stamp: 0
[   44.170160 ] hardirqs last  enabled at (0): [&lt;0000000000000000&gt;] 0x0
[   44.170627 ] hardirqs last disabled at (0): [&lt;ffffffff814209ed&gt;] copy_process+0x132d/0x3e00
[   44.171240 ] softirqs last  enabled at (0): [&lt;ffffffff81420a1a&gt;] copy_process+0x135a/0x3e00
[   44.171852 ] softirqs last disabled at (0): [&lt;0000000000000000&gt;] 0x0
[   44.172318 ] Preemption disabled at:
[   44.172320 ] [&lt;ffffffffa009b0a9&gt;] nj_release+0x69/0x500 [netjet]
[   44.174441 ] Call Trace:
[   44.174630 ]  dump_stack_lvl+0xa8/0xd1
[   44.174912 ]  dump_stack+0x15/0x17
[   44.175166 ]  ___might_sleep+0x3a2/0x510
[   44.175459 ]  ? nj_release+0x69/0x500 [netjet]
[   44.175791 ]  __might_sleep+0x82/0xe0
[   44.176063 ]  ? start_flush_work+0x20/0x7b0
[   44.176375 ]  start_flush_work+0x33/0x7b0
[   44.176672 ]  ? trace_irq_enable_rcuidle+0x85/0x170
[   44.177034 ]  ? kasan_quarantine_put+0xaa/0x1f0
[   44.177372 ]  ? kasan_quarantine_put+0xaa/0x1f0
[   44.177711 ]  __flush_work+0x11a/0x1a0
[   44.177991 ]  ? flush_work+0x20/0x20
[   44.178257 ]  ? lock_release+0x13c/0x8f0
[   44.178550 ]  ? __kasan_check_write+0x14/0x20
[   44.178872 ]  ? do_raw_spin_lock+0x148/0x360
[   44.179187 ]  ? read_lock_is_recursive+0x20/0x20
[   44.179530 ]  ? __kasan_check_read+0x11/0x20
[   44.179846 ]  ? do_raw_spin_unlock+0x55/0x900
[   44.180168 ]  ? ____kasan_slab_free+0x116/0x140
[   44.180505 ]  ? _raw_spin_unlock_irqrestore+0x41/0x60
[   44.180878 ]  ? skb_queue_purge+0x1a3/0x1c0
[   44.181189 ]  ? kfree+0x13e/0x290
[   44.181438 ]  flush_work+0x17/0x20
[   44.181695 ]  mISDN_freedchannel+0xe8/0x100
[   44.182006 ]  isac_release+0x210/0x260 [mISDNipac]
[   44.182366 ]  nj_release+0xf6/0x500 [netjet]
[   44.182685 ]  nj_remove+0x48/0x70 [netjet]
[   44.182989 ]  pci_device_remove+0xa9/0x250</Note>
    </Notes>
    <CVE>CVE-2021-47468</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 pointer dereference in i40e_dbg_dump_desc

When trying to dump VFs VSI RX/TX descriptors
using debugfs there was a crash
due to NULL pointer dereference in i40e_dbg_dump_desc.
Added a check to i40e_dbg_dump_desc that checks if
VSI type is correct for dumping RX/TX descriptors.</Note>
    </Notes>
    <CVE>CVE-2021-47501</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix memory leak in nfp_cpp_area_cache_add()

In line 800 (#1), nfp_cpp_area_alloc() allocates and initializes a
CPP area structure. But in line 807 (#2), when the cache is allocated
failed, this CPP area structure is not freed, which will result in
memory leak.

We can fix it by freeing the CPP area when the cache is allocated
failed (#2).

792 int nfp_cpp_area_cache_add(struct nfp_cpp *cpp, size_t size)
793 {
794 	struct nfp_cpp_area_cache *cache;
795 	struct nfp_cpp_area *area;

800	area = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0),
801 				  0, size);
	// #1: allocates and initializes

802 	if (!area)
803 		return -ENOMEM;

805 	cache = kzalloc(sizeof(*cache), GFP_KERNEL);
806 	if (!cache)
807 		return -ENOMEM; // #2: missing free

817	return 0;
818 }</Note>
    </Notes>
    <CVE>CVE-2021-47516</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings()

In qlcnic_83xx_add_rings(), the indirect function of
ahw-&gt;hw_ops-&gt;alloc_mbx_args will be called to allocate memory for
cmd.req.arg, and there is a dereference of it in qlcnic_83xx_add_rings(),
which could lead to a NULL pointer dereference on failure of the
indirect function like qlcnic_83xx_alloc_mbx_args().

Fix this bug by adding a check of alloc_mbx_args(), this patch
imitates the logic of mbx_cmd()'s failure handling.

This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.

Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.

Builds with CONFIG_QLCNIC=m show no new warnings, and our
static analyzer no longer warns about this code.</Note>
    </Notes>
    <CVE>CVE-2021-47542</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl

When the `rmmod sata_fsl.ko` command is executed in the PPC64 GNU/Linux,
a bug is reported:
 ==================================================================
 BUG: Unable to handle kernel data access on read at 0x80000800805b502c
 Oops: Kernel access of bad area, sig: 11 [#1]
 NIP [c0000000000388a4] .ioread32+0x4/0x20
 LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl]
 Call Trace:
  .free_irq+0x1c/0x4e0 (unreliable)
  .ata_host_stop+0x74/0xd0 [libata]
  .release_nodes+0x330/0x3f0
  .device_release_driver_internal+0x178/0x2c0
  .driver_detach+0x64/0xd0
  .bus_remove_driver+0x70/0xf0
  .driver_unregister+0x38/0x80
  .platform_driver_unregister+0x14/0x30
  .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl]
  .__se_sys_delete_module+0x1ec/0x2d0
  .system_call_exception+0xfc/0x1f0
  system_call_common+0xf8/0x200
 ==================================================================

The triggering of the BUG is shown in the following stack:

driver_detach
  device_release_driver_internal
    __device_release_driver
      drv-&gt;remove(dev) --&gt; platform_drv_remove/platform_remove
        drv-&gt;remove(dev) --&gt; sata_fsl_remove
          iounmap(host_priv-&gt;hcr_base);			&lt;---- unmap
          kfree(host_priv);                             &lt;---- free
      devres_release_all
        release_nodes
          dr-&gt;node.release(dev, dr-&gt;data) --&gt; ata_host_stop
            ap-&gt;ops-&gt;port_stop(ap) --&gt; sata_fsl_port_stop
                ioread32(hcr_base + HCONTROL)           &lt;---- UAF
            host-&gt;ops-&gt;host_stop(host)

The iounmap(host_priv-&gt;hcr_base) and kfree(host_priv) functions should
not be executed in drv-&gt;remove. These functions should be executed in
host_stop after port_stop. Therefore, we move these functions to the
new function sata_fsl_host_stop and bind the new function to host_stop.</Note>
    </Notes>
    <CVE>CVE-2021-47549</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 type in min_t to avoid stack OOB

Change min_t() to use type "u32" instead of type "int" to avoid stack out
of bounds. With min_t() type "int" the values get sign extended and the
larger value gets used causing stack out of bounds.

BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline]
BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976
Read of size 127 at addr ffff888072607128 by task syz-executor.7/18707

CPU: 1 PID: 18707 Comm: syz-executor.7 Not tainted 5.15.0-syzk #1
Hardware name: Red Hat KVM, BIOS 1.13.0-2
Call Trace:
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106
 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:256
 __kasan_report mm/kasan/report.c:442 [inline]
 kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:459
 check_region_inline mm/kasan/generic.c:183 [inline]
 kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189
 memcpy+0x23/0x60 mm/kasan/shadow.c:65
 memcpy include/linux/fortify-string.h:191 [inline]
 sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976
 sg_copy_from_buffer+0x33/0x40 lib/scatterlist.c:1000
 fill_from_dev_buffer.part.34+0x82/0x130 drivers/scsi/scsi_debug.c:1162
 fill_from_dev_buffer drivers/scsi/scsi_debug.c:1888 [inline]
 resp_readcap16+0x365/0x3b0 drivers/scsi/scsi_debug.c:1887
 schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478
 scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533
 scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline]
 scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699
 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639
 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325
 blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358
 __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761
 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838
 blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891
 blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474
 blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62
 sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:836
 sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:774
 sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:939
 sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:874 [inline]
 __se_sys_ioctl fs/ioctl.c:860 [inline]
 __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae</Note>
    </Notes>
    <CVE>CVE-2021-47580</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: Make do_proc_control() and do_proc_bulk() killable

The USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke
usb_start_wait_urb(), which contains an uninterruptible wait with a
user-specified timeout value.  If timeout value is very large and the
device being accessed does not respond in a reasonable amount of time,
the kernel will complain about "Task X blocked for more than N
seconds", as found in testing by syzbot:

INFO: task syz-executor.0:8700 blocked for more than 143 seconds.
      Not tainted 5.14.0-rc7-syzkaller #0
"echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor.0  state:D stack:23192 pid: 8700 ppid:  8455 flags:0x00004004
Call Trace:
 context_switch kernel/sched/core.c:4681 [inline]
 __schedule+0xc07/0x11f0 kernel/sched/core.c:5938
 schedule+0x14b/0x210 kernel/sched/core.c:6017
 schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857
 do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85
 __wait_for_common kernel/sched/completion.c:106 [inline]
 wait_for_common kernel/sched/completion.c:117 [inline]
 wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157
 usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63
 do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236
 proc_bulk drivers/usb/core/devio.c:1273 [inline]
 usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline]
 usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713
...

To fix this problem, this patch replaces usbfs's calls to
usb_control_msg() and usb_bulk_msg() with special-purpose code that
does essentially the same thing (as recommended in the comment for
usb_start_wait_urb()), except that it always uses a killable wait and
it uses GFP_KERNEL rather than GFP_NOIO.</Note>
    </Notes>
    <CVE>CVE-2021-47582</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sit: do not call ipip6_dev_free() from sit_init_net()

ipip6_dev_free is sit dev-&gt;priv_destructor, already called
by register_netdevice() if something goes wrong.

Alternative would be to make ipip6_dev_free() robust against
multiple invocations, but other drivers do not implement this
strategy.

syzbot reported:

dst_release underflow
WARNING: CPU: 0 PID: 5059 at net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173
Modules linked in:
CPU: 1 PID: 5059 Comm: syz-executor.4 Not tainted 5.16.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c:173
Code: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 &lt;0f&gt; 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48
RSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246
RAX: d6894a925dd15a00 RBX: 00000000ffffffff RCX: 0000000000040000
RDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000
RBP: 0000000000000000 R08: ffffffff816a1f42 R09: ffffed1017344f2c
R10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358
R13: 1ffffffff1bfd305 R14: ffffe8ffffcb1358 R15: dffffc0000000000
FS:  00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160
 ipip6_dev_free net/ipv6/sit.c:1414 [inline]
 sit_init_net+0x229/0x550 net/ipv6/sit.c:1936
 ops_init+0x313/0x430 net/core/net_namespace.c:140
 setup_net+0x35b/0x9d0 net/core/net_namespace.c:326
 copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470
 create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110
 unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226
 ksys_unshare+0x57d/0xb50 kernel/fork.c:3075
 __do_sys_unshare kernel/fork.c:3146 [inline]
 __se_sys_unshare kernel/fork.c:3144 [inline]
 __x64_sys_unshare+0x34/0x40 kernel/fork.c:3144
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f66c882ce99
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
RAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000048040200
RBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2021-47588</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

inet_diag: fix kernel-infoleak for UDP sockets

KMSAN reported a kernel-infoleak [1], that can exploited
by unpriv users.

After analysis it turned out UDP was not initializing
r-&gt;idiag_expires. Other users of inet_sk_diag_fill()
might make the same mistake in the future, so fix this
in inet_sk_diag_fill().

[1]
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]
BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:156 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670
 instrument_copy_to_user include/linux/instrumented.h:121 [inline]
 copyout lib/iov_iter.c:156 [inline]
 _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670
 copy_to_iter include/linux/uio.h:155 [inline]
 simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519
 __skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425
 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533
 skb_copy_datagram_msg include/linux/skbuff.h:3657 [inline]
 netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974
 sock_recvmsg_nosec net/socket.c:944 [inline]
 sock_recvmsg net/socket.c:962 [inline]
 sock_read_iter+0x5a9/0x630 net/socket.c:1035
 call_read_iter include/linux/fs.h:2156 [inline]
 new_sync_read fs/read_write.c:400 [inline]
 vfs_read+0x1631/0x1980 fs/read_write.c:481
 ksys_read+0x28c/0x520 fs/read_write.c:619
 __do_sys_read fs/read_write.c:629 [inline]
 __se_sys_read fs/read_write.c:627 [inline]
 __x64_sys_read+0xdb/0x120 fs/read_write.c:627
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
 entry_SYSCALL_64_after_hwframe+0x44/0xae

Uninit was created at:
 slab_post_alloc_hook mm/slab.h:524 [inline]
 slab_alloc_node mm/slub.c:3251 [inline]
 __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974
 kmalloc_reserve net/core/skbuff.c:354 [inline]
 __alloc_skb+0x545/0xf90 net/core/skbuff.c:426
 alloc_skb include/linux/skbuff.h:1126 [inline]
 netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245
 __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370
 netlink_dump_start include/linux/netlink.h:254 [inline]
 inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343
 sock_diag_rcv_msg+0x24a/0x620
 netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491
 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276
 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
 netlink_unicast+0x1095/0x1360 net/netlink/af_netlink.c:1345
 netlink_sendmsg+0x16f3/0x1870 net/netlink/af_netlink.c:1916
 sock_sendmsg_nosec net/socket.c:704 [inline]
 sock_sendmsg net/socket.c:724 [inline]
 sock_write_iter+0x594/0x690 net/socket.c:1057
 do_iter_readv_writev+0xa7f/0xc70
 do_iter_write+0x52c/0x1500 fs/read_write.c:851
 vfs_writev fs/read_write.c:924 [inline]
 do_writev+0x63f/0xe30 fs/read_write.c:967
 __do_sys_writev fs/read_write.c:1040 [inline]
 __se_sys_writev fs/read_write.c:1037 [inline]
 __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
 entry_SYSCALL_64_after_hwframe+0x44/0xae

Bytes 68-71 of 312 are uninitialized
Memory access of size 312 starts at ffff88812ab54000
Data copied to user address 0000000020001440

CPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011</Note>
    </Notes>
    <CVE>CVE-2021-47597</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

btrfs: use latest_dev in btrfs_show_devname

The test case btrfs/238 reports the warning below:

 WARNING: CPU: 3 PID: 481 at fs/btrfs/super.c:2509 btrfs_show_devname+0x104/0x1e8 [btrfs]
 CPU: 2 PID: 1 Comm: systemd Tainted: G        W  O 5.14.0-rc1-custom #72
 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
 Call trace:
   btrfs_show_devname+0x108/0x1b4 [btrfs]
   show_mountinfo+0x234/0x2c4
   m_show+0x28/0x34
   seq_read_iter+0x12c/0x3c4
   vfs_read+0x29c/0x2c8
   ksys_read+0x80/0xec
   __arm64_sys_read+0x28/0x34
   invoke_syscall+0x50/0xf8
   do_el0_svc+0x88/0x138
   el0_svc+0x2c/0x8c
   el0t_64_sync_handler+0x84/0xe4
   el0t_64_sync+0x198/0x19c

Reason:
While btrfs_prepare_sprout() moves the fs_devices::devices into
fs_devices::seed_list, the btrfs_show_devname() searches for the devices
and found none, leading to the warning as in above.

Fix:
latest_dev is updated according to the changes to the device list.
That means we could use the latest_dev-&gt;name to show the device name in
/proc/self/mounts, the pointer will be always valid as it's assigned
before the device is deleted from the list in remove or replace.
The RCU protection is sufficient as the device structure is freed after
synchronization.</Note>
    </Notes>
    <CVE>CVE-2021-47599</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: netlink: af_netlink: Prevent empty skb by adding a check on len.

Adding a check on len parameter to avoid empty skb. This prevents a
division error in netem_enqueue function which is caused when skb-&gt;len=0
and skb-&gt;data_len=0 in the randomized corruption step as shown below.

skb-&gt;data[prandom_u32() % skb_headlen(skb)] ^= 1&lt;&lt;(prandom_u32() % 8);

Crash Report:
[  343.170349] netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family
0 port 6081 - 0
[  343.216110] netem: version 1.3
[  343.235841] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
[  343.236680] CPU: 3 PID: 4288 Comm: reproducer Not tainted 5.16.0-rc1+
[  343.237569] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.11.0-2.el7 04/01/2014
[  343.238707] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem]
[  343.239499] Code: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ff
ff 8b 8d 50 ff ff ff 8b 85 58 ff ff ff 48 8b bd 70 ff ff ff 31 d2 2b 4f
74 &lt;f7&gt; f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03
[  343.241883] RSP: 0018:ffff88800bcd7368 EFLAGS: 00010246
[  343.242589] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX:
0000000000000000
[  343.243542] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI:
ffff88800f8eda40
[  343.244474] RBP: ffff88800bcd7458 R08: 0000000000000000 R09:
ffffffff94fb8445
[  343.245403] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12:
0000000000000000
[  343.246355] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15:
0000000000000020
[  343.247291] FS:  00007fdde2bd7700(0000) GS:ffff888109780000(0000)
knlGS:0000000000000000
[  343.248350] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  343.249120] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4:
00000000000006e0
[  343.250076] Call Trace:
[  343.250423]  &lt;TASK&gt;
[  343.250713]  ? memcpy+0x4d/0x60
[  343.251162]  ? netem_init+0xa0/0xa0 [sch_netem]
[  343.251795]  ? __sanitizer_cov_trace_pc+0x21/0x60
[  343.252443]  netem_enqueue+0xe28/0x33c0 [sch_netem]
[  343.253102]  ? stack_trace_save+0x87/0xb0
[  343.253655]  ? filter_irq_stacks+0xb0/0xb0
[  343.254220]  ? netem_init+0xa0/0xa0 [sch_netem]
[  343.254837]  ? __kasan_check_write+0x14/0x20
[  343.255418]  ? _raw_spin_lock+0x88/0xd6
[  343.255953]  dev_qdisc_enqueue+0x50/0x180
[  343.256508]  __dev_queue_xmit+0x1a7e/0x3090
[  343.257083]  ? netdev_core_pick_tx+0x300/0x300
[  343.257690]  ? check_kcov_mode+0x10/0x40
[  343.258219]  ? _raw_spin_unlock_irqrestore+0x29/0x40
[  343.258899]  ? __kasan_init_slab_obj+0x24/0x30
[  343.259529]  ? setup_object.isra.71+0x23/0x90
[  343.260121]  ? new_slab+0x26e/0x4b0
[  343.260609]  ? kasan_poison+0x3a/0x50
[  343.261118]  ? kasan_unpoison+0x28/0x50
[  343.261637]  ? __kasan_slab_alloc+0x71/0x90
[  343.262214]  ? memcpy+0x4d/0x60
[  343.262674]  ? write_comp_data+0x2f/0x90
[  343.263209]  ? __kasan_check_write+0x14/0x20
[  343.263802]  ? __skb_clone+0x5d6/0x840
[  343.264329]  ? __sanitizer_cov_trace_pc+0x21/0x60
[  343.264958]  dev_queue_xmit+0x1c/0x20
[  343.265470]  netlink_deliver_tap+0x652/0x9c0
[  343.266067]  netlink_unicast+0x5a0/0x7f0
[  343.266608]  ? netlink_attachskb+0x860/0x860
[  343.267183]  ? __sanitizer_cov_trace_pc+0x21/0x60
[  343.267820]  ? write_comp_data+0x2f/0x90
[  343.268367]  netlink_sendmsg+0x922/0xe80
[  343.268899]  ? netlink_unicast+0x7f0/0x7f0
[  343.269472]  ? __sanitizer_cov_trace_pc+0x21/0x60
[  343.270099]  ? write_comp_data+0x2f/0x90
[  343.270644]  ? netlink_unicast+0x7f0/0x7f0
[  343.271210]  sock_sendmsg+0x155/0x190
[  343.271721]  ____sys_sendmsg+0x75f/0x8f0
[  343.272262]  ? kernel_sendmsg+0x60/0x60
[  343.272788]  ? write_comp_data+0x2f/0x90
[  343.273332]  ? write_comp_data+0x2f/0x90
[  343.273869]  ___sys_sendmsg+0x10f/0x190
[  343.274405]  ? sendmsg_copy_msghdr+0x80/0x80
[  343.274984]  ? slab_post_alloc_hook+0x70/0x230
[  343.275597]  ? futex_wait_setup+0x240/0x240
[  343.276175]  ? security_file_alloc+0x3e/0x170
[  343.276779]  ? write_comp_d
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47606</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix segfault in nfc_genl_dump_devices_done

When kmalloc in nfc_genl_dump_devices() fails then
nfc_genl_dump_devices_done() segfaults as below

KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014
Workqueue: events netlink_sock_destruct_work
RIP: 0010:klist_iter_exit+0x26/0x80
Call Trace:
&lt;TASK&gt;
class_dev_iter_exit+0x15/0x20
nfc_genl_dump_devices_done+0x3b/0x50
genl_lock_done+0x84/0xd0
netlink_sock_destruct+0x8f/0x270
__sk_destruct+0x64/0x3b0
sk_destruct+0xa8/0xd0
__sk_free+0x2e8/0x3d0
sk_free+0x51/0x90
netlink_sock_destruct_work+0x1c/0x20
process_one_work+0x411/0x710
worker_thread+0x6fd/0xa80</Note>
    </Notes>
    <CVE>CVE-2021-47612</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 queues reservation for XDP

When XDP was configured on a system with large number of CPUs
and X722 NIC there was a call trace with NULL pointer dereference.

i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12
i40e 0000:87:00.0: setup of MAIN VSI failed

BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e]
Call Trace:
? i40e_reconfig_rss_queues+0x130/0x130 [i40e]
dev_xdp_install+0x61/0xe0
dev_xdp_attach+0x18a/0x4c0
dev_change_xdp_fd+0x1e6/0x220
do_setlink+0x616/0x1030
? ahci_port_stop+0x80/0x80
? ata_qc_issue+0x107/0x1e0
? lock_timer_base+0x61/0x80
? __mod_timer+0x202/0x380
rtnl_setlink+0xe5/0x170
? bpf_lsm_binder_transaction+0x10/0x10
? security_capable+0x36/0x50
rtnetlink_rcv_msg+0x121/0x350
? rtnl_calcit.isra.0+0x100/0x100
netlink_rcv_skb+0x50/0xf0
netlink_unicast+0x1d3/0x2a0
netlink_sendmsg+0x22a/0x440
sock_sendmsg+0x5e/0x60
__sys_sendto+0xf0/0x160
? __sys_getsockname+0x7e/0xc0
? _copy_from_user+0x3c/0x80
? __sys_setsockopt+0xc8/0x1a0
__x64_sys_sendto+0x20/0x30
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f83fa7a39e0

This was caused by PF queue pile fragmentation due to
flow director VSI queue being placed right after main VSI.
Because of this main VSI was not able to resize its
queue allocation for XDP resulting in no queues allocated
for main VSI when XDP was turned on.

Fix this by always allocating last queue in PF queue pile
for a flow director VSI.</Note>
    </Notes>
    <CVE>CVE-2021-47619</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Product: AndroidVersions: Android kernelAndroid ID: A-224546354References: Upstream kernel</Note>
    </Notes>
    <CVE>CVE-2022-20368</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2022-2964. Reason: This candidate is a reservation duplicate of CVE-2022-2964. Notes: All CVE users should reference CVE-2022-2964 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.</Note>
    </Notes>
    <CVE>CVE-2022-28748</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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/smc: Transitional solution for clcsock race issue

We encountered a crash in smc_setsockopt() and it is caused by
accessing smc-&gt;clcsock after clcsock was released.

 BUG: kernel NULL pointer dereference, address: 0000000000000020
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] PREEMPT SMP PTI
 CPU: 1 PID: 50309 Comm: nginx Kdump: loaded Tainted: G E     5.16.0-rc4+ #53
 RIP: 0010:smc_setsockopt+0x59/0x280 [smc]
 Call Trace:
  &lt;TASK&gt;
  __sys_setsockopt+0xfc/0x190
  __x64_sys_setsockopt+0x20/0x30
  do_syscall_64+0x34/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae
 RIP: 0033:0x7f16ba83918e
  &lt;/TASK&gt;

This patch tries to fix it by holding clcsock_release_lock and
checking whether clcsock has already been released before access.

In case that a crash of the same reason happens in smc_getsockopt()
or smc_switch_to_fallback(), this patch also checkes smc-&gt;clcsock
in them too. And the caller of smc_switch_to_fallback() will identify
whether fallback succeeds according to the return value.</Note>
    </Notes>
    <CVE>CVE-2022-48751</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: avoid EFIv2 runtime services on Apple x86 machines

Aditya reports [0] that his recent MacbookPro crashes in the firmware
when using the variable services at runtime. The culprit appears to be a
call to QueryVariableInfo(), which we did not use to call on Apple x86
machines in the past as they only upgraded from EFI v1.10 to EFI v2.40
firmware fairly recently, and QueryVariableInfo() (along with
UpdateCapsule() et al) was added in EFI v2.00.

The only runtime service introduced in EFI v2.00 that we actually use in
Linux is QueryVariableInfo(), as the capsule based ones are optional,
generally not used at runtime (all the LVFS/fwupd firmware update
infrastructure uses helper EFI programs that invoke capsule update at
boot time, not runtime), and not implemented by Apple machines in the
first place. QueryVariableInfo() is used to 'safely' set variables,
i.e., only when there is enough space. This prevents machines with buggy
firmwares from corrupting their NVRAMs when they run out of space.

Given that Apple machines have been using EFI v1.10 services only for
the longest time (the EFI v2.0 spec was released in 2006, and Linux
support for the newly introduced runtime services was added in 2011, but
the MacbookPro12,1 released in 2015 still claims to be EFI v1.10 only),
let's avoid the EFI v2.0 ones on all Apple x86 machines.

[0] https://lore.kernel.org/all/6D757C75-65B1-468B-842D-10410081A8E4@live.com/</Note>
    </Notes>
    <CVE>CVE-2022-48769</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj

kobject_init_and_add() takes reference even when it fails.
According to the doc of kobject_init_and_add():

   If this function returns an error, kobject_put() must be called to
   properly clean up the memory associated with the object.

Fix memory leak by calling kobject_put().</Note>
    </Notes>
    <CVE>CVE-2022-48775</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

vsock: remove vsock from connected table when connect is interrupted by a signal

vsock_connect() expects that the socket could already be in the
TCP_ESTABLISHED state when the connecting task wakes up with a signal
pending. If this happens the socket will be in the connected table, and
it is not removed when the socket state is reset. In this situation it's
common for the process to retry connect(), and if the connection is
successful the socket will be added to the connected table a second
time, corrupting the list.

Prevent this by calling vsock_remove_connected() if a signal is received
while waiting for a connection. This is harmless if the socket is not in
the connected table, and if it is in the table then removing it will
prevent list corruption from a double add.

Note for backporting: this patch requires d5afa82c977e ("vsock: correct
removal of socket from the list"), which is in all current stable trees
except 4.9.y.</Note>
    </Notes>
    <CVE>CVE-2022-48786</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvme-rdma: fix possible use-after-free in transport error_recovery work

While nvme_rdma_submit_async_event_work is checking the ctrl and queue
state before preparing the AER command and scheduling io_work, in order
to fully prevent a race where this check is not reliable the error
recovery work must flush async_event_work before continuing to destroy
the admin queue after setting the ctrl state to RESETTING such that
there is no race .submit_async_event and the error recovery handler
itself changing the ctrl state.</Note>
    </Notes>
    <CVE>CVE-2022-48788</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 possible use-after-free in transport error_recovery work

While nvme_tcp_submit_async_event_work is checking the ctrl and queue
state before preparing the AER command and scheduling io_work, in order
to fully prevent a race where this check is not reliable the error
recovery work must flush async_event_work before continuing to destroy
the admin queue after setting the ctrl state to RESETTING such that
there is no race .submit_async_event and the error recovery handler
itself changing the ctrl state.</Note>
    </Notes>
    <CVE>CVE-2022-48789</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix a possible use-after-free in controller reset during load

Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl
readiness for AER submission. This may lead to a use-after-free
condition that was observed with nvme-tcp.

The race condition may happen in the following scenario:
1. driver executes its reset_ctrl_work
2. -&gt; nvme_stop_ctrl - flushes ctrl async_event_work
3. ctrl sends AEN which is received by the host, which in turn
   schedules AEN handling
4. teardown admin queue (which releases the queue socket)
5. AEN processed, submits another AER, calling the driver to submit
6. driver attempts to send the cmd
==&gt; use-after-free

In order to fix that, add ctrl state check to validate the ctrl
is actually able to accept the AER submission.

This addresses the above race in controller resets because the driver
during teardown should:
1. change ctrl state to RESETTING
2. flush async_event_work (as well as other async work elements)

So after 1,2, any other AER command will find the
ctrl state to be RESETTING and bail out without submitting the AER.</Note>
    </Notes>
    <CVE>CVE-2022-48790</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pm8001: Fix use-after-free for aborted TMF sas_task

Currently a use-after-free may occur if a TMF sas_task is aborted before we
handle the IO completion in mpi_ssp_completion(). The abort occurs due to
timeout.

When the timeout occurs, the SAS_TASK_STATE_ABORTED flag is set and the
sas_task is freed in pm8001_exec_internal_tmf_task().

However, if the I/O completion occurs later, the I/O completion still
thinks that the sas_task is available. Fix this by clearing the ccb-&gt;task
if the TMF times out - the I/O completion handler does nothing if this
pointer is cleared.</Note>
    </Notes>
    <CVE>CVE-2022-48791</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pm8001: Fix use-after-free for aborted SSP/STP sas_task

Currently a use-after-free may occur if a sas_task is aborted by the upper
layer before we handle the I/O completion in mpi_ssp_completion() or
mpi_sata_completion().

In this case, the following are the two steps in handling those I/O
completions:

 - Call complete() to inform the upper layer handler of completion of
   the I/O.

 - Release driver resources associated with the sas_task in
   pm8001_ccb_task_free() call.

When complete() is called, the upper layer may free the sas_task. As such,
we should not touch the associated sas_task afterwards, but we do so in the
pm8001_ccb_task_free() call.

Fix by swapping the complete() and pm8001_ccb_task_free() calls ordering.</Note>
    </Notes>
    <CVE>CVE-2022-48792</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: ieee802154: at86rf230: Stop leaking skb's

Upon error the ieee802154_xmit_complete() helper is not called. Only
ieee802154_wake_queue() is called manually. In the Tx case we then leak
the skb structure.

Free the skb structure upon error before returning when appropriate.

As the 'is_tx = 0' cannot be moved in the complete handler because of a
possible race between the delay in switching to STATE_RX_AACK_ON and a
new interrupt, we introduce an intermediate 'was_tx' boolean just for
this purpose.

There is no Fixes tag applying here, many changes have been made on this
area and the issue kind of always existed.</Note>
    </Notes>
    <CVE>CVE-2022-48794</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

perf: Fix list corruption in perf_cgroup_switch()

There's list corruption on cgrp_cpuctx_list. This happens on the
following path:

  perf_cgroup_switch: list_for_each_entry(cgrp_cpuctx_list)
      cpu_ctx_sched_in
         ctx_sched_in
            ctx_pinned_sched_in
              merge_sched_in
                  perf_cgroup_event_disable: remove the event from the list

Use list_for_each_entry_safe() to allow removing an entry during
iteration.</Note>
    </Notes>
    <CVE>CVE-2022-48799</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vt_ioctl: fix array_index_nospec in vt_setactivate

array_index_nospec ensures that an out-of-bounds value is set to zero
on the transient path. Decreasing the value by one afterwards causes
a transient integer underflow. vsa.console should be decreased first
and then sanitized with array_index_nospec.

Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh
Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU
Amsterdam.</Note>
    </Notes>
    <CVE>CVE-2022-48804</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: fix a memleak when uncloning an skb dst and its metadata

When uncloning an skb dst and its associated metadata, a new
dst+metadata is allocated and later replaces the old one in the skb.
This is helpful to have a non-shared dst+metadata attached to a specific
skb.

The issue is the uncloned dst+metadata is initialized with a refcount of
1, which is increased to 2 before attaching it to the skb. When
tun_dst_unclone returns, the dst+metadata is only referenced from a
single place (the skb) while its refcount is 2. Its refcount will never
drop to 0 (when the skb is consumed), leading to a memory leak.

Fix this by removing the call to dst_hold in tun_dst_unclone, as the
dst+metadata refcount is already 1.</Note>
    </Notes>
    <CVE>CVE-2022-48809</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipmr,ip6mr: acquire RTNL before calling ip[6]mr_free_table() on failure path

ip[6]mr_free_table() can only be called under RTNL lock.

RTNL: assertion failed at net/core/dev.c (10367)
WARNING: CPU: 1 PID: 5890 at net/core/dev.c:10367 unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367
Modules linked in:
CPU: 1 PID: 5890 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller-11627-g422ee58dc0ef #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367
Code: 0f 85 9b ee ff ff e8 69 07 4b fa ba 7f 28 00 00 48 c7 c6 00 90 ae 8a 48 c7 c7 40 90 ae 8a c6 05 6d b1 51 06 01 e8 8c 90 d8 01 &lt;0f&gt; 0b e9 70 ee ff ff e8 3e 07 4b fa 4c 89 e7 e8 86 2a 59 fa e9 ee
RSP: 0018:ffffc900046ff6e0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff888050f51d00 RSI: ffffffff815fa008 RDI: fffff520008dfece
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815f3d6e R11: 0000000000000000 R12: 00000000fffffff4
R13: dffffc0000000000 R14: ffffc900046ff750 R15: ffff88807b7dc000
FS:  00007f4ab736e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fee0b4f8990 CR3: 000000001e7d2000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 mroute_clean_tables+0x244/0xb40 net/ipv6/ip6mr.c:1509
 ip6mr_free_table net/ipv6/ip6mr.c:389 [inline]
 ip6mr_rules_init net/ipv6/ip6mr.c:246 [inline]
 ip6mr_net_init net/ipv6/ip6mr.c:1306 [inline]
 ip6mr_net_init+0x3f0/0x4e0 net/ipv6/ip6mr.c:1298
 ops_init+0xaf/0x470 net/core/net_namespace.c:140
 setup_net+0x54f/0xbb0 net/core/net_namespace.c:331
 copy_net_ns+0x318/0x760 net/core/net_namespace.c:475
 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110
 copy_namespaces+0x391/0x450 kernel/nsproxy.c:178
 copy_process+0x2e0c/0x7300 kernel/fork.c:2167
 kernel_clone+0xe7/0xab0 kernel/fork.c:2555
 __do_sys_clone+0xc8/0x110 kernel/fork.c:2672
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f4ab89f9059
Code: Unable to access opcode bytes at RIP 0x7f4ab89f902f.
RSP: 002b:00007f4ab736e118 EFLAGS: 00000206 ORIG_RAX: 0000000000000038
RAX: ffffffffffffffda RBX: 00007f4ab8b0bf60 RCX: 00007f4ab89f9059
RDX: 0000000020000280 RSI: 0000000020000270 RDI: 0000000040200000
RBP: 00007f4ab8a5308d R08: 0000000020000300 R09: 0000000020000300
R10: 00000000200002c0 R11: 0000000000000206 R12: 0000000000000000
R13: 00007ffc3977cc1f R14: 00007f4ab736e300 R15: 0000000000022000
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2022-48810</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ibmvnic: don't release napi in __ibmvnic_open()

If __ibmvnic_open() encounters an error such as when setting link state,
it calls release_resources() which frees the napi structures needlessly.
Instead, have __ibmvnic_open() only clean up the work it did so far (i.e.
disable napi and irqs) and leave the rest to the callers.

If caller of __ibmvnic_open() is ibmvnic_open(), it should release the
resources immediately. If the caller is do_reset() or do_hard_reset(),
they will release the resources on the next reset.

This fixes following crash that occurred when running the drmgr command
several times to add/remove a vnic interface:

	[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq
	[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq
	[102056] ibmvnic 30000003 env3: Replenished 8 pools
	Kernel attempted to read user page (10) - exploit attempt? (uid: 0)
	BUG: Kernel NULL pointer dereference on read at 0x00000010
	Faulting instruction address: 0xc000000000a3c840
	Oops: Kernel access of bad area, sig: 11 [#1]
	LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
	...
	CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1
	Workqueue: events_long __ibmvnic_reset [ibmvnic]
	NIP:  c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820
	REGS: c0000000548e37e0 TRAP: 0300   Not tainted  (5.16.0-rc5-autotest-g6441998e2e37)
	MSR:  8000000000009033 &lt;SF,EE,ME,IR,DR,RI,LE&gt;  CR: 28248484  XER: 00000004
	CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0
	GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000
	...
	NIP [c000000000a3c840] napi_enable+0x20/0xc0
	LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]
	Call Trace:
	[c0000000548e3a80] [0000000000000006] 0x6 (unreliable)
	[c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]
	[c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]
	[c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570
	[c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660
	[c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0
	[c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
	Instruction dump:
	7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010
	38a0fff6 e92d1100 f9210028 39200000 &lt;e9030010&gt; f9010020 60420000 e9210020
	---[ end trace 5f8033b08fd27706 ]---</Note>
    </Notes>
    <CVE>CVE-2022-48811</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: qedf: Fix refcount issue when LOGO is received during TMF

Hung task call trace was seen during LOGO processing.

[  974.309060] [0000:00:00.0]:[qedf_eh_device_reset:868]: 1:0:2:0: LUN RESET Issued...
[  974.309065] [0000:00:00.0]:[qedf_initiate_tmf:2422]: tm_flags 0x10 sc_cmd 00000000c16b930f op = 0x2a target_id = 0x2 lun=0
[  974.309178] [0000:00:00.0]:[qedf_initiate_tmf:2431]: portid=016900 tm_flags =LUN RESET
[  974.309222] [0000:00:00.0]:[qedf_initiate_tmf:2438]: orig io_req = 00000000ec78df8f xid = 0x180 ref_cnt = 1.
[  974.309625] host1: rport 016900: Received LOGO request while in state Ready
[  974.309627] host1: rport 016900: Delete port
[  974.309642] host1: rport 016900: work event 3
[  974.309644] host1: rport 016900: lld callback ev 3
[  974.313243] [0000:61:00.2]:[qedf_execute_tmf:2383]:1: fcport is uploading, not executing flush.
[  974.313295] [0000:61:00.2]:[qedf_execute_tmf:2400]:1: task mgmt command success...
[  984.031088] INFO: task jbd2/dm-15-8:7645 blocked for more than 120 seconds.
[  984.031136]       Not tainted 4.18.0-305.el8.x86_64 #1

[  984.031166] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  984.031209] jbd2/dm-15-8    D    0  7645      2 0x80004080
[  984.031212] Call Trace:
[  984.031222]  __schedule+0x2c4/0x700
[  984.031230]  ? unfreeze_partials.isra.83+0x16e/0x1a0
[  984.031233]  ? bit_wait_timeout+0x90/0x90
[  984.031235]  schedule+0x38/0xa0
[  984.031238]  io_schedule+0x12/0x40
[  984.031240]  bit_wait_io+0xd/0x50
[  984.031243]  __wait_on_bit+0x6c/0x80
[  984.031248]  ? free_buffer_head+0x21/0x50
[  984.031251]  out_of_line_wait_on_bit+0x91/0xb0
[  984.031257]  ? init_wait_var_entry+0x50/0x50
[  984.031268]  jbd2_journal_commit_transaction+0x112e/0x19f0 [jbd2]
[  984.031280]  kjournald2+0xbd/0x270 [jbd2]
[  984.031284]  ? finish_wait+0x80/0x80
[  984.031291]  ? commit_timeout+0x10/0x10 [jbd2]
[  984.031294]  kthread+0x116/0x130
[  984.031300]  ? kthread_flush_work_fn+0x10/0x10
[  984.031305]  ret_from_fork+0x1f/0x40

There was a ref count issue when LOGO is received during TMF. This leads to
one of the I/Os hanging with the driver. Fix the ref count.</Note>
    </Notes>
    <CVE>CVE-2022-48823</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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/vc4: Fix deadlock on DSI device attach error

DSI device attach to DSI host will be done with host device's lock
held.

Un-registering host in "device attach" error path (ex: probe retry)
will result in deadlock with below call trace and non operational
DSI display.

Startup Call trace:
[   35.043036]  rt_mutex_slowlock.constprop.21+0x184/0x1b8
[   35.043048]  mutex_lock_nested+0x7c/0xc8
[   35.043060]  device_del+0x4c/0x3e8
[   35.043075]  device_unregister+0x20/0x40
[   35.043082]  mipi_dsi_remove_device_fn+0x18/0x28
[   35.043093]  device_for_each_child+0x68/0xb0
[   35.043105]  mipi_dsi_host_unregister+0x40/0x90
[   35.043115]  vc4_dsi_host_attach+0xf0/0x120 [vc4]
[   35.043199]  mipi_dsi_attach+0x30/0x48
[   35.043209]  tc358762_probe+0x128/0x164 [tc358762]
[   35.043225]  mipi_dsi_drv_probe+0x28/0x38
[   35.043234]  really_probe+0xc0/0x318
[   35.043244]  __driver_probe_device+0x80/0xe8
[   35.043254]  driver_probe_device+0xb8/0x118
[   35.043263]  __device_attach_driver+0x98/0xe8
[   35.043273]  bus_for_each_drv+0x84/0xd8
[   35.043281]  __device_attach+0xf0/0x150
[   35.043290]  device_initial_probe+0x1c/0x28
[   35.043300]  bus_probe_device+0xa4/0xb0
[   35.043308]  deferred_probe_work_func+0xa0/0xe0
[   35.043318]  process_one_work+0x254/0x700
[   35.043330]  worker_thread+0x4c/0x448
[   35.043339]  kthread+0x19c/0x1a8
[   35.043348]  ret_from_fork+0x10/0x20

Shutdown Call trace:
[  365.565417] Call trace:
[  365.565423]  __switch_to+0x148/0x200
[  365.565452]  __schedule+0x340/0x9c8
[  365.565467]  schedule+0x48/0x110
[  365.565479]  schedule_timeout+0x3b0/0x448
[  365.565496]  wait_for_completion+0xac/0x138
[  365.565509]  __flush_work+0x218/0x4e0
[  365.565523]  flush_work+0x1c/0x28
[  365.565536]  wait_for_device_probe+0x68/0x158
[  365.565550]  device_shutdown+0x24/0x348
[  365.565561]  kernel_restart_prepare+0x40/0x50
[  365.565578]  kernel_restart+0x20/0x70
[  365.565591]  __do_sys_reboot+0x10c/0x220
[  365.565605]  __arm64_sys_reboot+0x2c/0x38
[  365.565619]  invoke_syscall+0x4c/0x110
[  365.565634]  el0_svc_common.constprop.3+0xfc/0x120
[  365.565648]  do_el0_svc+0x2c/0x90
[  365.565661]  el0_svc+0x4c/0xf0
[  365.565671]  el0t_64_sync_handler+0x90/0xb8
[  365.565682]  el0t_64_sync+0x180/0x184</Note>
    </Notes>
    <CVE>CVE-2022-48826</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NFSD: Fix the behavior of READ near OFFSET_MAX

Dan Aloni reports:
&gt; Due to commit 8cfb9015280d ("NFS: Always provide aligned buffers to
&gt; the RPC read layers") on the client, a read of 0xfff is aligned up
&gt; to server rsize of 0x1000.
&gt;
&gt; As a result, in a test where the server has a file of size
&gt; 0x7fffffffffffffff, and the client tries to read from the offset
&gt; 0x7ffffffffffff000, the read causes loff_t overflow in the server
&gt; and it returns an NFS code of EINVAL to the client. The client as
&gt; a result indefinitely retries the request.

The Linux NFS client does not handle NFS?ERR_INVAL, even though all
NFS specifications permit servers to return that status code for a
READ.

Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed
and return a short result. Set the EOF flag in the result to prevent
the client from retrying the READ request. This behavior appears to
be consistent with Solaris NFS servers.

Note that NFSv3 and NFSv4 use u64 offset values on the wire. These
must be converted to loff_t internally before use -- an implicit
type cast is not adequate for this purpose. Otherwise VFS checks
against sb-&gt;s_maxbytes do not work properly.</Note>
    </Notes>
    <CVE>CVE-2022-48827</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NFSD: Fix ia_size underflow

iattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and
NFSv4 both define file size as an unsigned 64-bit type. Thus there
is a range of valid file size values an NFS client can send that is
already larger than Linux can handle.

Currently decode_fattr4() dumps a full u64 value into ia_size. If
that value happens to be larger than S64_MAX, then ia_size
underflows. I'm about to fix up the NFSv3 behavior as well, so let's
catch the underflow in the common code path: nfsd_setattr().</Note>
    </Notes>
    <CVE>CVE-2022-48828</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NFSD: Fix NFSv3 SETATTR/CREATE's handling of large file sizes

iattr::ia_size is a loff_t, so these NFSv3 procedures must be
careful to deal with incoming client size values that are larger
than s64_max without corrupting the value.

Silently capping the value results in storing a different value
than the client passed in which is unexpected behavior, so remove
the min_t() check in decode_sattr3().

Note that RFC 1813 permits only the WRITE procedure to return
NFS3ERR_FBIG. We believe that NFSv3 reference implementations
also return NFS3ERR_FBIG when ia_size is too large.</Note>
    </Notes>
    <CVE>CVE-2022-48829</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Input: aiptek - properly check endpoint type

Syzbot reported warning in usb_submit_urb() which is caused by wrong
endpoint type. There was a check for the number of endpoints, but not
for the type of endpoint.

Fix it by replacing old desc.bNumEndpoints check with
usb_find_common_endpoints() helper for finding endpoints

Fail log:

usb 5-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
Modules linked in:
CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
Workqueue: usb_hub_wq hub_event
...
Call Trace:
 &lt;TASK&gt;
 aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830
 input_open_device+0x1bb/0x320 drivers/input/input.c:629
 kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593</Note>
    </Notes>
    <CVE>CVE-2022-48836</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_core: Fix leaking sent_cmd skb

sent_cmd memory is not freed before freeing hci_dev causing it to leak
it contents.</Note>
    </Notes>
    <CVE>CVE-2022-48844</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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-sysfs: add check for netdevice being present to speed_show

When bringing down the netdevice or system shutdown, a panic can be
triggered while accessing the sysfs path because the device is already
removed.

    [  755.549084] mlx5_core 0000:12:00.1: Shutdown was called
    [  756.404455] mlx5_core 0000:12:00.0: Shutdown was called
    ...
    [  757.937260] BUG: unable to handle kernel NULL pointer dereference at           (null)
    [  758.031397] IP: [&lt;ffffffff8ee11acb&gt;] dma_pool_alloc+0x1ab/0x280

    crash&gt; bt
    ...
    PID: 12649  TASK: ffff8924108f2100  CPU: 1   COMMAND: "amsd"
    ...
     #9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
        [exception RIP: dma_pool_alloc+0x1ab]
        RIP: ffffffff8ee11acb  RSP: ffff89240e1a3968  RFLAGS: 00010046
        RAX: 0000000000000246  RBX: ffff89243d874100  RCX: 0000000000001000
        RDX: 0000000000000000  RSI: 0000000000000246  RDI: ffff89243d874090
        RBP: ffff89240e1a39c0   R8: 000000000001f080   R9: ffff8905ffc03c00
        R10: ffffffffc04680d4  R11: ffffffff8edde9fd  R12: 00000000000080d0
        R13: ffff89243d874090  R14: ffff89243d874080  R15: 0000000000000000
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
    #10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
    #11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
    #12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
    #13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
    #14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
    #15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
    #16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
    #17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
    #18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
    #19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
    #20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
    #21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
    #22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
    #23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
    #24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
    #25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
    #26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92

    crash&gt; net_device.state ffff89443b0c0000
      state = 0x5  (__LINK_STATE_START| __LINK_STATE_NOCARRIER)

To prevent this scenario, we also make sure that the netdevice is present.</Note>
    </Notes>
    <CVE>CVE-2022-48850</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

swiotlb: fix info leak with DMA_FROM_DEVICE

The problem I'm addressing was discovered by the LTP test covering
cve-2018-1000204.

A short description of what happens follows:
1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO
   interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV
   and a corresponding dxferp. The peculiar thing about this is that TUR
   is not reading from the device.
2) In sg_start_req() the invocation of blk_rq_map_user() effectively
   bounces the user-space buffer. As if the device was to transfer into
   it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in
   sg_build_indirect()") we make sure this first bounce buffer is
   allocated with GFP_ZERO.
3) For the rest of the story we keep ignoring that we have a TUR, so the
   device won't touch the buffer we prepare as if the we had a
   DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device
   and the  buffer allocated by SG is mapped by the function
   virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here
   scatter-gather and not scsi generics). This mapping involves bouncing
   via the swiotlb (we need swiotlb to do virtio in protected guest like
   s390 Secure Execution, or AMD SEV).
4) When the SCSI TUR is done, we first copy back the content of the second
   (that is swiotlb) bounce buffer (which most likely contains some
   previous IO data), to the first bounce buffer, which contains all
   zeros.  Then we copy back the content of the first bounce buffer to
   the user-space buffer.
5) The test case detects that the buffer, which it zero-initialized,
  ain't all zeros and fails.

One can argue that this is an swiotlb problem, because without swiotlb
we leak all zeros, and the swiotlb should be transparent in a sense that
it does not affect the outcome (if all other participants are well
behaved).

Copying the content of the original buffer into the swiotlb buffer is
the only way I can think of to make swiotlb transparent in such
scenarios. So let's do just that if in doubt, but allow the driver
to tell us that the whole mapped buffer is going to be overwritten,
in which case we can preserve the old behavior and avoid the performance
impact of the extra bounce.</Note>
    </Notes>
    <CVE>CVE-2022-48853</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sctp: fix kernel-infoleak for SCTP sockets

syzbot reported a kernel infoleak [1] of 4 bytes.

After analysis, it turned out r-&gt;idiag_expires is not initialized
if inet_sctp_diag_fill() calls inet_diag_msg_common_fill()

Make sure to clear idiag_timer/idiag_retrans/idiag_expires
and let inet_diag_msg_sctpasoc_fill() fill them again if needed.

[1]

BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]
BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668
 instrument_copy_to_user include/linux/instrumented.h:121 [inline]
 copyout lib/iov_iter.c:154 [inline]
 _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668
 copy_to_iter include/linux/uio.h:162 [inline]
 simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519
 __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425
 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533
 skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline]
 netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977
 sock_recvmsg_nosec net/socket.c:948 [inline]
 sock_recvmsg net/socket.c:966 [inline]
 __sys_recvfrom+0x795/0xa10 net/socket.c:2097
 __do_sys_recvfrom net/socket.c:2115 [inline]
 __se_sys_recvfrom net/socket.c:2111 [inline]
 __x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
 entry_SYSCALL_64_after_hwframe+0x44/0xae

Uninit was created at:
 slab_post_alloc_hook mm/slab.h:737 [inline]
 slab_alloc_node mm/slub.c:3247 [inline]
 __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975
 kmalloc_reserve net/core/skbuff.c:354 [inline]
 __alloc_skb+0x545/0xf90 net/core/skbuff.c:426
 alloc_skb include/linux/skbuff.h:1158 [inline]
 netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248
 __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373
 netlink_dump_start include/linux/netlink.h:254 [inline]
 inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341
 sock_diag_rcv_msg+0x24a/0x620
 netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494
 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277
 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
 netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343
 netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919
 sock_sendmsg_nosec net/socket.c:705 [inline]
 sock_sendmsg net/socket.c:725 [inline]
 sock_write_iter+0x594/0x690 net/socket.c:1061
 do_iter_readv_writev+0xa7f/0xc70
 do_iter_write+0x52c/0x1500 fs/read_write.c:851
 vfs_writev fs/read_write.c:924 [inline]
 do_writev+0x645/0xe00 fs/read_write.c:967
 __do_sys_writev fs/read_write.c:1040 [inline]
 __se_sys_writev fs/read_write.c:1037 [inline]
 __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
 entry_SYSCALL_64_after_hwframe+0x44/0xae

Bytes 68-71 of 2508 are uninitialized
Memory access of size 2508 starts at ffff888114f9b000
Data copied to user address 00007f7fe09ff2e0

CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011</Note>
    </Notes>
    <CVE>CVE-2022-48855</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: port100: fix use-after-free in port100_send_complete

Syzbot reported UAF in port100_send_complete(). The root case is in
missing usb_kill_urb() calls on error handling path of -&gt;probe function.

port100_send_complete() accesses devm allocated memory which will be
freed on probe failure. We should kill this urbs before returning an
error from probe function to prevent reported use-after-free

Fail log:

BUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
Read of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26
...
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
 print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255
 __kasan_report mm/kasan/report.c:442 [inline]
 kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
 port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935
 __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670

...

Allocated by task 1255:
 kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
 kasan_set_track mm/kasan/common.c:45 [inline]
 set_alloc_info mm/kasan/common.c:436 [inline]
 ____kasan_kmalloc mm/kasan/common.c:515 [inline]
 ____kasan_kmalloc mm/kasan/common.c:474 [inline]
 __kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524
 alloc_dr drivers/base/devres.c:116 [inline]
 devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823
 devm_kzalloc include/linux/device.h:209 [inline]
 port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502

Freed by task 1255:
 kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38
 kasan_set_track+0x21/0x30 mm/kasan/common.c:45
 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370
 ____kasan_slab_free mm/kasan/common.c:366 [inline]
 ____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328
 kasan_slab_free include/linux/kasan.h:236 [inline]
 __cache_free mm/slab.c:3437 [inline]
 kfree+0xf8/0x2b0 mm/slab.c:3794
 release_nodes+0x112/0x1a0 drivers/base/devres.c:501
 devres_release_all+0x114/0x190 drivers/base/devres.c:530
 really_probe+0x626/0xcc0 drivers/base/dd.c:670</Note>
    </Notes>
    <CVE>CVE-2022-48857</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ethernet: Fix error handling in xemaclite_of_probe

This node pointer is returned by of_parse_phandle() with refcount
incremented in this function. Calling of_node_put() to avoid the
refcount leak. As the remove function do.</Note>
    </Notes>
    <CVE>CVE-2022-48860</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mISDN: Fix memory leak in dsp_pipeline_build()

dsp_pipeline_build() allocates dup pointer by kstrdup(cfg),
but then it updates dup variable by strsep(&amp;dup, "|").
As a result when it calls kfree(dup), the dup variable contains NULL.

Found by Linux Driver Verification project (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2022-48863</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tipc: fix kernel panic when enabling bearer

When enabling a bearer on a node, a kernel panic is observed:

[    4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]
...
[    4.520030] Call Trace:
[    4.520689]  &lt;IRQ&gt;
[    4.521236]  tipc_link_build_proto_msg+0x375/0x750 [tipc]
[    4.522654]  tipc_link_build_state_msg+0x48/0xc0 [tipc]
[    4.524034]  __tipc_node_link_up+0xd7/0x290 [tipc]
[    4.525292]  tipc_rcv+0x5da/0x730 [tipc]
[    4.526346]  ? __netif_receive_skb_core+0xb7/0xfc0
[    4.527601]  tipc_l2_rcv_msg+0x5e/0x90 [tipc]
[    4.528737]  __netif_receive_skb_list_core+0x20b/0x260
[    4.530068]  netif_receive_skb_list_internal+0x1bf/0x2e0
[    4.531450]  ? dev_gro_receive+0x4c2/0x680
[    4.532512]  napi_complete_done+0x6f/0x180
[    4.533570]  virtnet_poll+0x29c/0x42e [virtio_net]
...

The node in question is receiving activate messages in another
thread after changing bearer status to allow message sending/
receiving in current thread:

         thread 1           |              thread 2
         --------           |              --------
                            |
tipc_enable_bearer()        |
  test_and_set_bit_lock()   |
    tipc_bearer_xmit_skb()  |
                            | tipc_l2_rcv_msg()
                            |   tipc_rcv()
                            |     __tipc_node_link_up()
                            |       tipc_link_build_state_msg()
                            |         tipc_link_build_proto_msg()
                            |           tipc_mon_prep()
                            |           {
                            |             ...
                            |             // null-pointer dereference
                            |             u16 gen = mon-&gt;dom_gen;
                            |             ...
                            |           }
  // Not being executed yet |
  tipc_mon_create()         |
  {                         |
    ...                     |
    // allocate             |
    mon = kzalloc();        |
    ...                     |
  }                         |

Monitoring pointer in thread 2 is dereferenced before monitoring data
is allocated in thread 1. This causes kernel panic.

This commit fixes it by allocating the monitoring data before enabling
the bearer to receive messages.</Note>
    </Notes>
    <CVE>CVE-2022-48865</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sdata can be NULL during AMPDU start

ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a
deauthentication is ongoing.

Here a trace triggering the race with the hostapd test
multi_ap_fronthaul_on_ap:

(gdb) list *drv_ampdu_action+0x46
0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396).
391             int ret = -EOPNOTSUPP;
392
393             might_sleep();
394
395             sdata = get_bss_sdata(sdata);
396             if (!check_sdata_in_driver(sdata))
397                     return -EIO;
398
399             trace_drv_ampdu_action(local, sdata, params);
400

wlan0: moving STA 02:00:00:00:03:00 to state 3
wlan0: associated
wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING)
wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0
wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port)
wlan0: moving STA 02:00:00:00:03:00 to state 2
wlan0: moving STA 02:00:00:00:03:00 to state 1
wlan0: Removed STA 02:00:00:00:03:00
wlan0: Destroyed STA 02:00:00:00:03:00
BUG: unable to handle page fault for address: fffffffffffffb48
PGD 11814067 P4D 11814067 PUD 11816067 PMD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G        W          6.1.0-rc8-wt+ #59
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
Workqueue: phy3 ieee80211_ba_session_work [mac80211]
RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211]
Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 &lt;8b&gt; 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85
RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287
RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240
RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40
RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0
R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8
FS:  0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0
Call Trace:
 &lt;TASK&gt;
 ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211]
 ieee80211_ba_session_work+0xff/0x2e0 [mac80211]
 process_one_work+0x29f/0x620
 worker_thread+0x4d/0x3d0
 ? process_one_work+0x620/0x620
 kthread+0xfb/0x120
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x22/0x30
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2022-48875</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ixgbe: fix pci device refcount leak

As the comment of pci_get_domain_bus_and_slot() says, it
returns a PCI device with refcount incremented, when finish
using it, the caller must decrement the reference count by
calling pci_dev_put().

In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(),
pci_dev_put() is called to avoid leak.</Note>
    </Notes>
    <CVE>CVE-2022-48896</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/virtio: Fix GEM handle creation UAF

Userspace can guess the handle value and try to race GEM object creation
with handle close, resulting in a use-after-free if we dereference the
object after dropping the handle's reference.  For that reason, dropping
the handle's reference must be done *after* we are done dereferencing
the object.</Note>
    </Notes>
    <CVE>CVE-2022-48899</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ibmvnic: free reset-work-item when flushing

Fix a tiny memory leak when flushing the reset work queue.</Note>
    </Notes>
    <CVE>CVE-2022-48905</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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: ipv6: ensure we call ipv6_mc_down() at most once

There are two reasons for addrconf_notify() to be called with NETDEV_DOWN:
either the network device is actually going down, or IPv6 was disabled
on the interface.

If either of them stays down while the other is toggled, we repeatedly
call the code for NETDEV_DOWN, including ipv6_mc_down(), while never
calling the corresponding ipv6_mc_up() in between. This will cause a
new entry in idev-&gt;mc_tomb to be allocated for each multicast group
the interface is subscribed to, which in turn leaks one struct ifmcaddr6
per nontrivial multicast group the interface is subscribed to.

The following reproducer will leak at least $n objects:

ip addr add ff2e::4242/32 dev eth0 autojoin
sysctl -w net.ipv6.conf.eth0.disable_ipv6=1
for i in $(seq 1 $n); do
	ip link set up eth0; ip link set down eth0
done

Joining groups with IPV6_ADD_MEMBERSHIP (unprivileged) or setting the
sysctl net.ipv6.conf.eth0.forwarding to 1 (=&gt; subscribing to ff02::2)
can also be used to create a nontrivial idev-&gt;mc_list, which will the
leak objects with the right up-down-sequence.

Based on both sources for NETDEV_DOWN events the interface IPv6 state
should be considered:

 - not ready if the network interface is not ready OR IPv6 is disabled
   for it
 - ready if the network interface is ready AND IPv6 is enabled for it

The functions ipv6_mc_up() and ipv6_down() should only be run when this
state changes.

Implement this by remembering when the IPv6 state is ready, and only
run ipv6_mc_down() if it actually changed from ready to not ready.

The other direction (not ready -&gt; ready) already works correctly, as:

 - the interface notification triggered codepath for NETDEV_UP /
   NETDEV_CHANGE returns early if ipv6 is disabled, and
 - the disable_ipv6=0 triggered codepath skips fully initializing the
   interface as long as addrconf_link_ready(dev) returns false
 - calling ipv6_mc_up() repeatedly does not leak anything</Note>
    </Notes>
    <CVE>CVE-2022-48910</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_queue: fix possible use-after-free

Eric Dumazet says:
  The sock_hold() side seems suspect, because there is no guarantee
  that sk_refcnt is not already 0.

On failure, we cannot queue the packet and need to indicate an
error.  The packet will be dropped by the caller.

v2: split skb prefetch hunk into separate change</Note>
    </Notes>
    <CVE>CVE-2022-48911</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cifs: fix double free race when mount fails in cifs_get_root()

When cifs_get_root() fails during cifs_smb3_do_mount() we call
deactivate_locked_super() which eventually will call delayed_free() which
will free the context.
In this situation we should not proceed to enter the out: section in
cifs_smb3_do_mount() and free the same resources a second time.

[Thu Feb 10 12:59:06 2022] BUG: KASAN: use-after-free in rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022] Read of size 8 at addr ffff888364f4d110 by task swapper/1/0

[Thu Feb 10 12:59:06 2022] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G           OE     5.17.0-rc3+ #4
[Thu Feb 10 12:59:06 2022] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019
[Thu Feb 10 12:59:06 2022] Call Trace:
[Thu Feb 10 12:59:06 2022]  &lt;IRQ&gt;
[Thu Feb 10 12:59:06 2022]  dump_stack_lvl+0x5d/0x78
[Thu Feb 10 12:59:06 2022]  print_address_description.constprop.0+0x24/0x150
[Thu Feb 10 12:59:06 2022]  ? rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022]  kasan_report.cold+0x7d/0x117
[Thu Feb 10 12:59:06 2022]  ? rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022]  __asan_load8+0x86/0xa0
[Thu Feb 10 12:59:06 2022]  rcu_cblist_dequeue+0x32/0x60
[Thu Feb 10 12:59:06 2022]  rcu_core+0x547/0xca0
[Thu Feb 10 12:59:06 2022]  ? call_rcu+0x3c0/0x3c0
[Thu Feb 10 12:59:06 2022]  ? __this_cpu_preempt_check+0x13/0x20
[Thu Feb 10 12:59:06 2022]  ? lock_is_held_type+0xea/0x140
[Thu Feb 10 12:59:06 2022]  rcu_core_si+0xe/0x10
[Thu Feb 10 12:59:06 2022]  __do_softirq+0x1d4/0x67b
[Thu Feb 10 12:59:06 2022]  __irq_exit_rcu+0x100/0x150
[Thu Feb 10 12:59:06 2022]  irq_exit_rcu+0xe/0x30
[Thu Feb 10 12:59:06 2022]  sysvec_hyperv_stimer0+0x9d/0xc0
...
[Thu Feb 10 12:59:07 2022] Freed by task 58179:
[Thu Feb 10 12:59:07 2022]  kasan_save_stack+0x26/0x50
[Thu Feb 10 12:59:07 2022]  kasan_set_track+0x25/0x30
[Thu Feb 10 12:59:07 2022]  kasan_set_free_info+0x24/0x40
[Thu Feb 10 12:59:07 2022]  ____kasan_slab_free+0x137/0x170
[Thu Feb 10 12:59:07 2022]  __kasan_slab_free+0x12/0x20
[Thu Feb 10 12:59:07 2022]  slab_free_freelist_hook+0xb3/0x1d0
[Thu Feb 10 12:59:07 2022]  kfree+0xcd/0x520
[Thu Feb 10 12:59:07 2022]  cifs_smb3_do_mount+0x149/0xbe0 [cifs]
[Thu Feb 10 12:59:07 2022]  smb3_get_tree+0x1a0/0x2e0 [cifs]
[Thu Feb 10 12:59:07 2022]  vfs_get_tree+0x52/0x140
[Thu Feb 10 12:59:07 2022]  path_mount+0x635/0x10c0
[Thu Feb 10 12:59:07 2022]  __x64_sys_mount+0x1bf/0x210
[Thu Feb 10 12:59:07 2022]  do_syscall_64+0x5c/0xc0
[Thu Feb 10 12:59:07 2022]  entry_SYSCALL_64_after_hwframe+0x44/0xae

[Thu Feb 10 12:59:07 2022] Last potentially related work creation:
[Thu Feb 10 12:59:07 2022]  kasan_save_stack+0x26/0x50
[Thu Feb 10 12:59:07 2022]  __kasan_record_aux_stack+0xb6/0xc0
[Thu Feb 10 12:59:07 2022]  kasan_record_aux_stack_noalloc+0xb/0x10
[Thu Feb 10 12:59:07 2022]  call_rcu+0x76/0x3c0
[Thu Feb 10 12:59:07 2022]  cifs_umount+0xce/0xe0 [cifs]
[Thu Feb 10 12:59:07 2022]  cifs_kill_sb+0xc8/0xe0 [cifs]
[Thu Feb 10 12:59:07 2022]  deactivate_locked_super+0x5d/0xd0
[Thu Feb 10 12:59:07 2022]  cifs_smb3_do_mount+0xab9/0xbe0 [cifs]
[Thu Feb 10 12:59:07 2022]  smb3_get_tree+0x1a0/0x2e0 [cifs]
[Thu Feb 10 12:59:07 2022]  vfs_get_tree+0x52/0x140
[Thu Feb 10 12:59:07 2022]  path_mount+0x635/0x10c0
[Thu Feb 10 12:59:07 2022]  __x64_sys_mount+0x1bf/0x210
[Thu Feb 10 12:59:07 2022]  do_syscall_64+0x5c/0xc0
[Thu Feb 10 12:59:07 2022]  entry_SYSCALL_64_after_hwframe+0x44/0xae</Note>
    </Notes>
    <CVE>CVE-2022-48919</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

btrfs: get rid of warning on transaction commit when using flushoncommit

When using the flushoncommit mount option, during almost every transaction
commit we trigger a warning from __writeback_inodes_sb_nr():

  $ cat fs/fs-writeback.c:
  (...)
  static void __writeback_inodes_sb_nr(struct super_block *sb, ...
  {
        (...)
        WARN_ON(!rwsem_is_locked(&amp;sb-&gt;s_umount));
        (...)
  }
  (...)

The trace produced in dmesg looks like the following:

  [947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3
  [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif
  [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186
  [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3
  [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...)
  [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246
  [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000
  [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50
  [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000
  [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488
  [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460
  [947.553621] FS:  0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000
  [947.560537] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0
  [947.571072] Call Trace:
  [947.572354]  &lt;TASK&gt;
  [947.573266]  btrfs_commit_transaction+0x1f1/0x998
  [947.576785]  ? start_transaction+0x3ab/0x44e
  [947.579867]  ? schedule_timeout+0x8a/0xdd
  [947.582716]  transaction_kthread+0xe9/0x156
  [947.585721]  ? btrfs_cleanup_transaction.isra.0+0x407/0x407
  [947.590104]  kthread+0x131/0x139
  [947.592168]  ? set_kthread_struct+0x32/0x32
  [947.595174]  ret_from_fork+0x22/0x30
  [947.597561]  &lt;/TASK&gt;
  [947.598553] ---[ end trace 644721052755541c ]---

This is because we started using writeback_inodes_sb() to flush delalloc
when committing a transaction (when using -o flushoncommit), in order to
avoid deadlocks with filesystem freeze operations. This change was made
by commit ce8ea7cc6eb313 ("btrfs: don't call btrfs_start_delalloc_roots
in flushoncommit"). After that change we started producing that warning,
and every now and then a user reports this since the warning happens too
often, it spams dmesg/syslog, and a user is unsure if this reflects any
problem that might compromise the filesystem's reliability.

We can not just lock the sb-&gt;s_umount semaphore before calling
writeback_inodes_sb(), because that would at least deadlock with
filesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()
is called while we are holding that semaphore in write mode, and that can
trigger a transaction commit, resulting in a deadlock. It would also
trigger the same type of deadlock in the unmount path. Possibly, it could
also introduce some other locking dependencies that lockdep would report.

To fix this call try_to_writeback_inodes_sb() instead of
writeback_inodes_sb(), because that will try to read lock sb-&gt;s_umount
and then will only call writeback_inodes_sb() if it was able to lock it.
This is fine because the cases where it can't read lock sb-&gt;s_umount
are during a filesystem unmount or during a filesystem freeze - in those
cases sb-&gt;s_umount is write locked and sync_filesystem() is called, which
calls writeback_inodes_sb(). In other words, in all cases where we can't
take a read lock on sb-&gt;s_umount, writeback is already being triggered
elsewhere.

An alternative would be to call btrfs_start_delalloc_roots() with a
number of pages different from LONG_MAX, for example matching the number
of delalloc bytes we currently have, in 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-48920</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ib_srp: Fix a deadlock

Remove the flush_workqueue(system_long_wq) call since flushing
system_long_wq is deadlock-prone and since that call is redundant with a
preceding cancel_work_sync()</Note>
    </Notes>
    <CVE>CVE-2022-48930</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

configfs: fix a race in configfs_{,un}register_subsystem()

When configfs_register_subsystem() or configfs_unregister_subsystem()
is executing link_group() or unlink_group(),
it is possible that two processes add or delete list concurrently.
Some unfortunate interleavings of them can cause kernel panic.

One of cases is:
A --&gt; B --&gt; C --&gt; D
A &lt;-- B &lt;-- C &lt;-- D

     delete list_head *B        |      delete list_head *C
--------------------------------|-----------------------------------
configfs_unregister_subsystem   |   configfs_unregister_subsystem
  unlink_group                  |     unlink_group
    unlink_obj                  |       unlink_obj
      list_del_init             |         list_del_init
        __list_del_entry        |           __list_del_entry
          __list_del            |             __list_del
            // next == C        |
            next-&gt;prev = prev   |
                                |               next-&gt;prev = prev
            prev-&gt;next = next   |
                                |                 // prev == B
                                |                 prev-&gt;next = next

Fix this by adding mutex when calling link_group() or unlink_group(),
but parent configfs_subsystem is NULL when config_item is root.
So I create a mutex configfs_subsystem_mutex.</Note>
    </Notes>
    <CVE>CVE-2022-48931</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

CDC-NCM: avoid overflow in sanity checking

A broken device may give an extreme offset like 0xFFF0
and a reasonable length for a fragment. In the sanity
check as formulated now, this will create an integer
overflow, defeating the sanity check. Both offset
and offset + len need to be checked in such a manner
that no overflow can occur.
And those quantities should be unsigned.</Note>
    </Notes>
    <CVE>CVE-2022-48938</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: x86/mmu: make apf token non-zero to fix bug

In current async pagefault logic, when a page is ready, KVM relies on
kvm_arch_can_dequeue_async_page_present() to determine whether to deliver
a READY event to the Guest. This function test token value of struct
kvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when a
READY event is finished by Guest. If value is zero meaning that a READY
event is done, so the KVM can deliver another.
But the kvm_arch_setup_async_pf() may produce a valid token with zero
value, which is confused with previous mention and may lead the loss of
this READY event.

This bug may cause task blocked forever in Guest:
 INFO: task stress:7532 blocked for more than 1254 seconds.
       Not tainted 5.10.0 #16
 "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 task:stress          state:D stack:    0 pid: 7532 ppid:  1409
 flags:0x00000080
 Call Trace:
  __schedule+0x1e7/0x650
  schedule+0x46/0xb0
  kvm_async_pf_task_wait_schedule+0xad/0xe0
  ? exit_to_user_mode_prepare+0x60/0x70
  __kvm_handle_async_pf+0x4f/0xb0
  ? asm_exc_page_fault+0x8/0x30
  exc_page_fault+0x6f/0x110
  ? asm_exc_page_fault+0x8/0x30
  asm_exc_page_fault+0x1e/0x30
 RIP: 0033:0x402d00
 RSP: 002b:00007ffd31912500 EFLAGS: 00010206
 RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0
 RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0
 RBP: 00000000021262b0 R08: 0000000000000003 R09: 0000000000000086
 R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000
 R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000</Note>
    </Notes>
    <CVE>CVE-2022-48943</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: vivid: fix compose size exceed boundary

syzkaller found a bug:

 BUG: unable to handle page fault for address: ffffc9000a3b1000
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0
 Oops: 0002 [#1] PREEMPT SMP
 CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
 RIP: 0010:memcpy_erms+0x6/0x10
[...]
 Call Trace:
  &lt;TASK&gt;
  ? tpg_fill_plane_buffer+0x856/0x15b0
  vivid_fillbuff+0x8ac/0x1110
  vivid_thread_vid_cap_tick+0x361/0xc90
  vivid_thread_vid_cap+0x21a/0x3a0
  kthread+0x143/0x180
  ret_from_fork+0x1f/0x30
  &lt;/TASK&gt;

This is because we forget to check boundary after adjust compose-&gt;height
int V4L2_SEL_TGT_CROP case. Add v4l2_rect_map_inside() to fix this problem
for this case.</Note>
    </Notes>
    <CVE>CVE-2022-48945</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

udf: Fix preallocation discarding at indirect extent boundary

When preallocation extent is the first one in the extent block, the
code would corrupt extent tree header instead. Fix the problem and use
udf_delete_aext() for deleting extent to avoid some code duplication.</Note>
    </Notes>
    <CVE>CVE-2022-48946</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

igb: Initialize mailbox message for VF reset

When a MAC address is not assigned to the VF, that portion of the message
sent to the VF is not set. The memory, however, is allocated from the
stack meaning that information may be leaked to the VM. Initialize the
message buffer to 0 so that no information is passed to the VM in this
case.</Note>
    </Notes>
    <CVE>CVE-2022-48949</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ops: Check bounds for second channel in snd_soc_put_volsw_sx()

The bounds checks in snd_soc_put_volsw_sx() are only being applied to the
first channel, meaning it is possible to write out of bounds values to the
second channel in stereo controls. Add appropriate checks.</Note>
    </Notes>
    <CVE>CVE-2022-48951</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipv6: avoid use-after-free in ip6_fragment()

Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers.

It seems to not be always true, at least for UDP stack.

syzbot reported:

BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline]
BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951
Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618

CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:284 [inline]
 print_report+0x15e/0x45d mm/kasan/report.c:395
 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495
 ip6_dst_idev include/net/ip6_fib.h:245 [inline]
 ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951
 __ip6_finish_output net/ipv6/ip6_output.c:193 [inline]
 ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206
 NF_HOOK_COND include/linux/netfilter.h:291 [inline]
 ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227
 dst_output include/net/dst.h:445 [inline]
 ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161
 ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966
 udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286
 udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313
 udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606
 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665
 sock_sendmsg_nosec net/socket.c:714 [inline]
 sock_sendmsg+0xd3/0x120 net/socket.c:734
 sock_write_iter+0x295/0x3d0 net/socket.c:1108
 call_write_iter include/linux/fs.h:2191 [inline]
 new_sync_write fs/read_write.c:491 [inline]
 vfs_write+0x9ed/0xdd0 fs/read_write.c:584
 ksys_write+0x1ec/0x250 fs/read_write.c:637
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fde3588c0d9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9
RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a
RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000
 &lt;/TASK&gt;

Allocated by task 7618:
 kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325
 kasan_slab_alloc include/linux/kasan.h:201 [inline]
 slab_post_alloc_hook mm/slab.h:737 [inline]
 slab_alloc_node mm/slub.c:3398 [inline]
 slab_alloc mm/slub.c:3406 [inline]
 __kmem_cache_alloc_lru mm/slub.c:3413 [inline]
 kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422
 dst_alloc+0x14a/0x1f0 net/core/dst.c:92
 ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344
 ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline]
 rt6_make_pcpu_route net/ipv6/route.c:1417 [inline]
 ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254
 pol_lookup_func include/net/ip6_fib.h:582 [inline]
 fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121
 ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625
 ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638
 ip6_route_output include/net/ip6_route.h:98 [inline]
 ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092
 ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222
 ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260
 udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554
 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665
 sock_sendmsg_nosec n
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-48956</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

ethernet: aeroflex: fix potential skb leak in greth_init_rings()

The greth_init_rings() function won't free the newly allocated skb when
dma_mapping_error() returns error, so add dev_kfree_skb() to fix it.

Compile tested only.</Note>
    </Notes>
    <CVE>CVE-2022-48958</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hisilicon: Fix potential use-after-free in hix5hd2_rx()

The skb is delivered to napi_gro_receive() which may free it, after
calling this, dereferencing skb may trigger use-after-free.</Note>
    </Notes>
    <CVE>CVE-2022-48960</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>critical</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: hisilicon: Fix potential use-after-free in hisi_femac_rx()

The skb is delivered to napi_gro_receive() which may free it, after
calling this, dereferencing skb may trigger use-after-free.</Note>
    </Notes>
    <CVE>CVE-2022-48962</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: mvneta: Prevent out of bounds read in mvneta_config_rss()

The pp-&gt;indir[0] value comes from the user.  It is passed to:

	if (cpu_online(pp-&gt;rxq_def))

inside the mvneta_percpu_elect() function.  It needs bounds checkeding
to ensure that it is not beyond the end of the cpu bitmap.</Note>
    </Notes>
    <CVE>CVE-2022-48966</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Bounds check struct nfc_target arrays

While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported:

  memcpy: detected field-spanning write (size 129) of single field "target-&gt;sensf_res" at net/nfc/nci/ntf.c:260 (size 18)

This appears to be a legitimate lack of bounds checking in
nci_add_new_protocol(). Add the missing checks.</Note>
    </Notes>
    <CVE>CVE-2022-48967</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

xen-netfront: Fix NULL sring after live migration

A NAPI is setup for each network sring to poll data to kernel
The sring with source host is destroyed before live migration and
new sring with target host is setup after live migration.
The NAPI for the old sring is not deleted until setup new sring
with target host after migration. With busy_poll/busy_read enabled,
the NAPI can be polled before got deleted when resume VM.

BUG: unable to handle kernel NULL pointer dereference at
0000000000000008
IP: xennet_poll+0xae/0xd20
PGD 0 P4D 0
Oops: 0000 [#1] SMP PTI
Call Trace:
 finish_task_switch+0x71/0x230
 timerqueue_del+0x1d/0x40
 hrtimer_try_to_cancel+0xb5/0x110
 xennet_alloc_rx_buffers+0x2a0/0x2a0
 napi_busy_loop+0xdb/0x270
 sock_poll+0x87/0x90
 do_sys_poll+0x26f/0x580
 tracing_map_insert+0x1d4/0x2f0
 event_hist_trigger+0x14a/0x260

 finish_task_switch+0x71/0x230
 __schedule+0x256/0x890
 recalc_sigpending+0x1b/0x50
 xen_sched_clock+0x15/0x20
 __rb_reserve_next+0x12d/0x140
 ring_buffer_lock_reserve+0x123/0x3d0
 event_triggers_call+0x87/0xb0
 trace_event_buffer_commit+0x1c4/0x210
 xen_clocksource_get_cycles+0x15/0x20
 ktime_get_ts64+0x51/0xf0
 SyS_ppoll+0x160/0x1a0
 SyS_ppoll+0x160/0x1a0
 do_syscall_64+0x73/0x130
 entry_SYSCALL_64_after_hwframe+0x41/0xa6
...
RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900
CR2: 0000000000000008
---[ end trace f8601785b354351c ]---

xen frontend should remove the NAPIs for the old srings before live
migration as the bond srings are destroyed

There is a tiny window between the srings are set to NULL and
the NAPIs are disabled, It is safe as the NAPI threads are still
frozen at that time</Note>
    </Notes>
    <CVE>CVE-2022-48969</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Fix not cleanup led when bt_init fails

bt_init() calls bt_leds_init() to register led, but if it fails later,
bt_leds_cleanup() is not called to unregister it.

This can cause panic if the argument "bluetooth-power" in text is freed
and then another led_trigger_register() tries to access it:

BUG: unable to handle page fault for address: ffffffffc06d3bc0
RIP: 0010:strcmp+0xc/0x30
  Call Trace:
    &lt;TASK&gt;
    led_trigger_register+0x10d/0x4f0
    led_trigger_register_simple+0x7d/0x100
    bt_init+0x39/0xf7 [bluetooth]
    do_one_initcall+0xd0/0x4e0</Note>
    </Notes>
    <CVE>CVE-2022-48971</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()

Kernel fault injection test reports null-ptr-deref as follows:

BUG: kernel NULL pointer dereference, address: 0000000000000008
RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114
Call Trace:
 &lt;TASK&gt;
 raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87
 call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944
 unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982
 unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879
 register_netdevice+0x9a8/0xb90 net/core/dev.c:10083
 ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659
 ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229
 mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316

ieee802154_if_add() allocates wpan_dev as netdev's private data, but not
init the list in struct wpan_dev. cfg802154_netdev_notifier_call() manage
the list when device register/unregister, and may lead to null-ptr-deref.

Use INIT_LIST_HEAD() on it to initialize it correctly.</Note>
    </Notes>
    <CVE>CVE-2022-48972</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: amd8111: Fix PCI device reference count leak

for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.

If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL
input parameter, there is no problem for the 'Device not found' branch.
For the normal path, add pci_dev_put() in amd_gpio_exit().</Note>
    </Notes>
    <CVE>CVE-2022-48973</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

HID: core: fix shift-out-of-bounds in hid_report_raw_event

Syzbot reported shift-out-of-bounds in hid_report_raw_event.

microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) &gt;
32! (swapper/0)
======================================================================
UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20
shift exponent 127 is too large for 32-bit type 'int'
CPU: 0 PID: 0 Comm: swapper/0 Not tainted
6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS
Google 10/26/2022
Call Trace:
 &lt;IRQ&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106
 ubsan_epilogue lib/ubsan.c:151 [inline]
 __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322
 snto32 drivers/hid/hid-core.c:1323 [inline]
 hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline]
 hid_process_report drivers/hid/hid-core.c:1665 [inline]
 hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998
 hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066
 hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284
 __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671
 dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988
 call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474
 expire_timers kernel/time/timer.c:1519 [inline]
 __run_timers+0x76a/0x980 kernel/time/timer.c:1790
 run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803
 __do_softirq+0x277/0x75b kernel/softirq.c:571
 __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650
 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662
 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107
======================================================================

If the size of the integer (unsigned n) is bigger than 32 in snto32(),
shift exponent will be too large for 32-bit type 'int', resulting in a
shift-out-of-bounds bug.
Fix this by adding a check on the size of the integer (unsigned n) in
snto32(). To add support for n greater than 32 bits, set n to 32, if n
is greater than 32.</Note>
    </Notes>
    <CVE>CVE-2022-48978</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: mana: Fix race on per-CQ variable napi work_done

After calling napi_complete_done(), the NAPIF_STATE_SCHED bit may be
cleared, and another CPU can start napi thread and access per-CQ variable,
cq-&gt;work_done. If the other thread (for example, from busy_poll) sets
it to a value &gt;= budget, this thread will continue to run when it should
stop, and cause memory corruption and panic.

To fix this issue, save the per-CQ work_done variable in a local variable
before napi_complete_done(), so it won't be corrupted by a possible
concurrent thread after napi_complete_done().

Also, add a flag bit to advertise to the NIC firmware: the NAPI work_done
variable race is fixed, so the driver is able to reliably support features
like busy_poll.</Note>
    </Notes>
    <CVE>CVE-2022-48985</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

memcg: fix possible use-after-free in memcg_write_event_control()

memcg_write_event_control() accesses the dentry-&gt;d_name of the specified
control fd to route the write call.  As a cgroup interface file can't be
renamed, it's safe to access d_name as long as the specified file is a
regular cgroup file.  Also, as these cgroup interface files can't be
removed before the directory, it's safe to access the parent too.

Prior to 347c4a874710 ("memcg: remove cgroup_event-&gt;cft"), there was a
call to __file_cft() which verified that the specified file is a regular
cgroupfs file before further accesses.  The cftype pointer returned from
__file_cft() was no longer necessary and the commit inadvertently dropped
the file type check with it allowing any file to slip through.  With the
invarients broken, the d_name and parent accesses can now race against
renames and removals of arbitrary files and cause use-after-free's.

Fix the bug by resurrecting the file type check in __file_cft().  Now that
cgroupfs is implemented through kernfs, checking the file operations needs
to go through a layer of indirection.  Instead, let's check the superblock
and dentry type.</Note>
    </Notes>
    <CVE>CVE-2022-48988</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths

Any codepath that zaps page table entries must invoke MMU notifiers to
ensure that secondary MMUs (like KVM) don't keep accessing pages which
aren't mapped anymore.  Secondary MMUs don't hold their own references to
pages that are mirrored over, so failing to notify them can lead to page
use-after-free.

I'm marking this as addressing an issue introduced in commit f3f0e1d2150b
("khugepaged: add support of collapse for tmpfs/shmem pages"), but most of
the security impact of this only came in commit 27e1f8273113 ("khugepaged:
enable collapse pmd for pte-mapped THP"), which actually omitted flushes
for the removal of present PTEs, not just for the removal of empty page
tables.</Note>
    </Notes>
    <CVE>CVE-2022-48991</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

ASoC: soc-pcm: Add NULL check in BE reparenting

Add NULL check in dpcm_be_reparent API, to handle
kernel NULL pointer dereference error.
The issue occurred in fuzzing test.</Note>
    </Notes>
    <CVE>CVE-2022-48992</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

char: tpm: Protect tpm_pm_suspend with locks

Currently tpm transactions are executed unconditionally in
tpm_pm_suspend() function, which may lead to races with other tpm
accessors in the system.

Specifically, the hw_random tpm driver makes use of tpm_get_random(),
and this function is called in a loop from a kthread, which means it's
not frozen alongside userspace, and so can race with the work done
during system suspend:

  tpm tpm0: tpm_transmit: tpm_recv: error -52
  tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics
  CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
  Call Trace:
   tpm_tis_status.cold+0x19/0x20
   tpm_transmit+0x13b/0x390
   tpm_transmit_cmd+0x20/0x80
   tpm1_pm_suspend+0xa6/0x110
   tpm_pm_suspend+0x53/0x80
   __pnp_bus_suspend+0x35/0xe0
   __device_suspend+0x10f/0x350

Fix this by calling tpm_try_get_ops(), which itself is a wrapper around
tpm_chip_start(), but takes the appropriate mutex.

[Jason: reworked commit message, added metadata]</Note>
    </Notes>
    <CVE>CVE-2022-48997</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

iommu/vt-d: Fix PCI device refcount leak in has_external_pci()

for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.

If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() before 'return true' to avoid reference count leak.</Note>
    </Notes>
    <CVE>CVE-2022-49000</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()

for_each_pci_dev() is implemented by pci_get_device(). The comment of
pci_get_device() says that it will increase the reference count for the
returned pci_dev and also decrease the reference count for the input
pci_dev @from if it is not NULL.

If we break for_each_pci_dev() loop with pdev not NULL, we need to call
pci_dev_put() to decrease the reference count. Add the missing
pci_dev_put() for the error path to avoid reference count leak.</Note>
    </Notes>
    <CVE>CVE-2022-49002</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

hwmon: (coretemp) Check for null before removing sysfs attrs

If coretemp_add_core() gets an error then pdata-&gt;core_data[indx]
is already NULL and has been kfreed. Don't pass that to
sysfs_remove_group() as that will crash in sysfs_remove_group().

[Shortened for readability]
[91854.020159] sysfs: cannot create duplicate filename '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label'
&lt;cpu offline&gt;
[91855.126115] BUG: kernel NULL pointer dereference, address: 0000000000000188
[91855.165103] #PF: supervisor read access in kernel mode
[91855.194506] #PF: error_code(0x0000) - not-present page
[91855.224445] PGD 0 P4D 0
[91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI
...
[91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80
...
[91855.796571] Call Trace:
[91855.810524]  coretemp_cpu_offline+0x12b/0x1dd [coretemp]
[91855.841738]  ? coretemp_cpu_online+0x180/0x180 [coretemp]
[91855.871107]  cpuhp_invoke_callback+0x105/0x4b0
[91855.893432]  cpuhp_thread_fun+0x8e/0x150
...

Fix this by checking for NULL first.</Note>
    </Notes>
    <CVE>CVE-2022-49010</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()

As comment of pci_get_domain_bus_and_slot() says, it returns
a pci device with refcount increment, when finish using it,
the caller must decrement the reference count by calling
pci_dev_put(). So call it after using to avoid refcount leak.</Note>
    </Notes>
    <CVE>CVE-2022-49011</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: tun: Fix use-after-free in tun_detach()

syzbot reported use-after-free in tun_detach() [1].  This causes call
trace like below:

==================================================================
BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75
Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673

CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:284 [inline]
 print_report+0x15e/0x461 mm/kasan/report.c:395
 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495
 notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75
 call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942
 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]
 call_netdevice_notifiers net/core/dev.c:1997 [inline]
 netdev_wait_allrefs_any net/core/dev.c:10237 [inline]
 netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351
 tun_detach drivers/net/tun.c:704 [inline]
 tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467
 __fput+0x27c/0xa90 fs/file_table.c:320
 task_work_run+0x16f/0x270 kernel/task_work.c:179
 exit_task_work include/linux/task_work.h:38 [inline]
 do_exit+0xb3d/0x2a30 kernel/exit.c:820
 do_group_exit+0xd4/0x2a0 kernel/exit.c:950
 get_signal+0x21b1/0x2440 kernel/signal.c:2858
 arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869
 exit_to_user_mode_loop kernel/entry/common.c:168 [inline]
 exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203
 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
 syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296
 do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

The cause of the issue is that sock_put() from __tun_detach() drops
last reference count for struct net, and then notifier_call_chain()
from netdev_state_change() accesses that struct net.

This patch fixes the issue by calling sock_put() from tun_detach()
after all necessary accesses for the struct net has done.</Note>
    </Notes>
    <CVE>CVE-2022-49014</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: hsr: Fix potential use-after-free

The skb is delivered to netif_rx() which may free it, after calling this,
dereferencing skb may trigger use-after-free.</Note>
    </Notes>
    <CVE>CVE-2022-49015</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/9p: Fix a potential socket leak in p9_socket_open

Both p9_fd_create_tcp() and p9_fd_create_unix() will call
p9_socket_open(). If the creation of p9_trans_fd fails,
p9_fd_create_tcp() and p9_fd_create_unix() will return an
error directly instead of releasing the cscoket, which will
result in a socket leak.

This patch adds sock_release() to fix the leak issue.</Note>
    </Notes>
    <CVE>CVE-2022-49020</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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: phy: fix null-ptr-deref while probe() failed

I got a null-ptr-deref report as following when doing fault injection test:

BUG: kernel NULL pointer dereference, address: 0000000000000058
Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G    B            N 6.1.0-rc3+
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:klist_put+0x2d/0xd0
Call Trace:
 &lt;TASK&gt;
 klist_remove+0xf1/0x1c0
 device_release_driver_internal+0x23e/0x2d0
 bus_remove_device+0x1bd/0x240
 device_del+0x357/0x770
 phy_device_remove+0x11/0x30
 mdiobus_unregister+0xa5/0x140
 release_nodes+0x6a/0xa0
 devres_release_all+0xf8/0x150
 device_unbind_cleanup+0x19/0xd0

//probe path:
phy_device_register()
  device_add()

phy_connect
  phy_attach_direct() //set device driver
    probe() //it's failed, driver is not bound
    device_bind_driver() // probe failed, it's not called

//remove path:
phy_device_remove()
  device_del()
    device_release_driver_internal()
      __device_release_driver() //dev-&gt;drv is not NULL
        klist_remove() &lt;- knode_driver is not added yet, cause null-ptr-deref

In phy_attach_direct(), after setting the 'dev-&gt;driver', probe() fails,
device_bind_driver() is not called, so the knode_driver-&gt;n_klist is not
set, then it causes null-ptr-deref in __device_release_driver() while
deleting device. Fix this by setting dev-&gt;driver to NULL in the error
path in phy_attach_direct().</Note>
    </Notes>
    <CVE>CVE-2022-49021</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

e100: Fix possible use after free in e100_xmit_prepare

In e100_xmit_prepare(), if we can't map the skb, then return -ENOMEM, so
e100_xmit_frame() will return NETDEV_TX_BUSY and the upper layer will
resend the skb. But the skb is already freed, which will cause UAF bug
when the upper layer resends the skb.

Remove the harmful free.</Note>
    </Notes>
    <CVE>CVE-2022-49026</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iavf: Fix error handling in iavf_init_module()

The iavf_init_module() won't destroy workqueue when pci_register_driver()
failed. Call destroy_workqueue() when pci_register_driver() failed to
prevent the resource leak.

Similar to the handling of u132_hcd_init in commit f276e002793c
("usb: u132-hcd: fix resource leak")</Note>
    </Notes>
    <CVE>CVE-2022-49027</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ixgbevf: Fix resource leak in ixgbevf_init_module()

ixgbevf_init_module() won't destroy the workqueue created by
create_singlethread_workqueue() when pci_register_driver() failed. Add
destroy_workqueue() in fail path to prevent the resource leak.

Similar to the handling of u132_hcd_init in commit f276e002793c
("usb: u132-hcd: fix resource leak")</Note>
    </Notes>
    <CVE>CVE-2022-49028</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails

Smatch report warning as follows:

drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn:
  '&amp;data-&gt;list' not removed from list

If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will
be freed, but data-&gt;list will not be removed from driver_data.bmc_data,
then list traversal may cause UAF.

Fix by removeing it from driver_data.bmc_data before free().</Note>
    </Notes>
    <CVE>CVE-2022-49029</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in compare_netdev_and_ip in drivers/infiniband/core/cma.c in RDMA in the Linux Kernel. The improper cleanup results in out-of-boundary read, where a local user can utilize this problem to crash the system or escalation of privilege.</Note>
    </Notes>
    <CVE>CVE-2023-2176</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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">OpenTelemetry-Go Contrib is a collection of third-party packages for OpenTelemetry-Go. A handler wrapper out of the box adds labels `http.user_agent` and `http.method` that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent to it. HTTP header User-Agent or HTTP method for requests can be easily set by an attacker to be random and long. The library internally uses `httpconv.ServerRequest` that records every value for HTTP `method` and `User-Agent`. In order to be affected, a program has to use the `otelhttp.NewHandler` wrapper and not filter any unknown HTTP methods or User agents on the level of CDN, LB, previous middleware, etc. Version 0.44.0 fixed this issue when the values collected for attribute `http.request.method` were changed to be restricted to a set of well-known values and other high cardinality attributes were removed. As a workaround to stop being affected, `otelhttp.WithFilter()` can be used, but it requires manual careful configuration to not log certain requests entirely. For convenience and safe usage of this library, it should by default mark with the label `unknown` non-standard HTTP methods and User agents to show that such requests were made but do not increase cardinality. In case someone wants to stay with the current behavior, library API should allow to enable it.</Note>
    </Notes>
    <CVE>CVE-2023-45142</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:containerd-1.7.23-16.97.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:docker-26.1.5_ce-98.120.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 attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.</Note>
    </Notes>
    <CVE>CVE-2023-45288</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:containerd-1.7.23-16.97.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel before 6.5.9, there is a NULL pointer dereference in send_acknowledge in net/nfc/nci/spi.c.</Note>
    </Notes>
    <CVE>CVE-2023-46343</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">OpenTelemetry-Go Contrib is a collection of third-party packages for OpenTelemetry-Go. Prior to version 0.46.0, the grpc Unary Server Interceptor out of the box adds labels `net.peer.sock.addr` and `net.peer.sock.port` that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent. An attacker can easily flood the peer address and port for requests. Version 0.46.0 contains a fix for this issue. As a workaround to stop being affected, a view removing the attributes can be used. The other possibility is to disable grpc metrics instrumentation by passing `otelgrpc.WithMeterProvider` option with `noop.NewMeterProvider`.</Note>
    </Notes>
    <CVE>CVE-2023-47108</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:containerd-1.7.23-16.97.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:docker-26.1.5_ce-98.120.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in the python-cryptography package. This issue may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.</Note>
    </Notes>
    <CVE>CVE-2023-50782</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libopenssl1_1-1.1.1d-2.113.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">libexpat through 2.5.0 allows a denial of service (resource consumption) because many full reparsings are required in the case of a large token for which multiple buffer fills are needed.</Note>
    </Notes>
    <CVE>CVE-2023-52425</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:expat-2.1.0-21.40.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libexpat1-2.1.0-21.40.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: prevent mss overflow in skb_segment()

Once again syzbot is able to crash the kernel in skb_segment() [1]

GSO_BY_FRAGS is a forbidden value, but unfortunately the following
computation in skb_segment() can reach it quite easily :

	mss = mss * partial_segs;

65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to
a bad final result.

Make sure to limit segmentation so that the new mss value is smaller
than GSO_BY_FRAGS.

[1]

general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;0f&gt; b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00
RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0
R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046
FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
&lt;TASK&gt;
udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109
ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120
skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53
__skb_gso_segment+0x339/0x710 net/core/gso.c:124
skb_gso_segment include/net/gso.h:83 [inline]
validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626
__dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
packet_xmit+0x257/0x380 net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3087 [inline]
packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0xd5/0x180 net/socket.c:745
__sys_sendto+0x255/0x340 net/socket.c:2190
__do_sys_sendto net/socket.c:2202 [inline]
__se_sys_sendto net/socket.c:2198 [inline]
__x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7f8692032aa9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9
RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003
RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480
R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003
&lt;/TASK&gt;
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;0f&gt; b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00
RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
RBP: ffffc90004347578 R0
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-52435</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus()

Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug
occurs when txs-&gt;cnt, data from a URB provided by a USB device, is
bigger than the size of the array txs-&gt;txstatus, which is
HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug
handling code after the check. Make the function return if that is the
case.

Found by a modified version of syzkaller.

UBSAN: array-index-out-of-bounds in htc_drv_txrx.c
index 13 is out of range for type '__wmi_event_txstatus [12]'
Call Trace:
 ath9k_htc_txstatus
 ath9k_wmi_event_tasklet
 tasklet_action_common
 __do_softirq
 irq_exit_rxu
 sysvec_apic_timer_interrupt</Note>
    </Notes>
    <CVE>CVE-2023-52594</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: scomp - fix req-&gt;dst buffer overflow

The req-&gt;dst buffer size should be checked before copying from the
scomp_scratch-&gt;dst to avoid req-&gt;dst buffer overflow problem.</Note>
    </Notes>
    <CVE>CVE-2023-52612</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

hwrng: core - Fix page fault dead lock on mmap-ed hwrng

There is a dead-lock in the hwrng device read path.  This triggers
when the user reads from /dev/hwrng into memory also mmap-ed from
/dev/hwrng.  The resulting page fault triggers a recursive read
which then dead-locks.

Fix this by using a stack buffer when calling copy_to_user.</Note>
    </Notes>
    <CVE>CVE-2023-52615</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ram: Fix crash when setting number of cpus to an odd number

When the number of cpu cores is adjusted to 7 or other odd numbers,
the zone size will become an odd number.
The address of the zone will become:
    addr of zone0 = BASE
    addr of zone1 = BASE + zone_size
    addr of zone2 = BASE + zone_size*2
    ...
The address of zone1/3/5/7 will be mapped to non-alignment va.
Eventually crashes will occur when accessing these va.

So, use ALIGN_DOWN() to make sure the zone size is even
to avoid this bug.</Note>
    </Notes>
    <CVE>CVE-2023-52619</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

SUNRPC: Fix a suspicious RCU usage warning

I received the following warning while running cthon against an ontap
server running pNFS:

[   57.202521] =============================
[   57.202522] WARNING: suspicious RCU usage
[   57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted
[   57.202525] -----------------------------
[   57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!!
[   57.202527]
               other info that might help us debug this:

[   57.202528]
               rcu_scheduler_active = 2, debug_locks = 1
[   57.202529] no locks held by test5/3567.
[   57.202530]
               stack backtrace:
[   57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e
[   57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022
[   57.202536] Call Trace:
[   57.202537]  &lt;TASK&gt;
[   57.202540]  dump_stack_lvl+0x77/0xb0
[   57.202551]  lockdep_rcu_suspicious+0x154/0x1a0
[   57.202556]  rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[   57.202596]  rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[   57.202621]  ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[   57.202646]  rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[   57.202671]  ? __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[   57.202696]  nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
[   57.202728]  ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
[   57.202754]  nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]
[   57.202760]  filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]
[   57.202765]  pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
[   57.202788]  __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[   57.202813]  nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[   57.202831]  nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[   57.202849]  nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[   57.202866]  write_cache_pages+0x265/0x450
[   57.202870]  ? __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[   57.202891]  nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[   57.202913]  do_writepages+0xd2/0x230
[   57.202917]  ? filemap_fdatawrite_wbc+0x5c/0x80
[   57.202921]  filemap_fdatawrite_wbc+0x67/0x80
[   57.202924]  filemap_write_and_wait_range+0xd9/0x170
[   57.202930]  nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[   57.202947]  nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
[   57.202969]  __se_sys_close+0x46/0xd0
[   57.202972]  do_syscall_64+0x68/0x100
[   57.202975]  ? do_syscall_64+0x77/0x100
[   57.202976]  ? do_syscall_64+0x77/0x100
[   57.202979]  entry_SYSCALL_64_after_hwframe+0x6e/0x76
[   57.202982] RIP: 0033:0x7fe2b12e4a94
[   57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3
[   57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX: 0000000000000003
[   57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94
[   57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003
[   57.202992] RBP: 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49
[   57.202993] R10: 00007f
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-52623</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: s390/aes - Fix buffer overread in CTR mode

When processing the last block, the s390 ctr code will always read
a whole block, even if there isn't a whole block of data left.  Fix
this by using the actual length left and copy it into a buffer first
for processing.</Note>
    </Notes>
    <CVE>CVE-2023-52669</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mmc: mmc_spi: fix error handling in mmc_spi_probe()

If mmc_add_host() fails, it doesn't need to call mmc_remove_host(),
or it will cause null-ptr-deref, because of deleting a not added
device in mmc_remove_host().

To fix this, goto label 'fail_glue_init', if mmc_add_host() fails,
and change the label 'fail_add_host' to 'fail_gpiod_request'.</Note>
    </Notes>
    <CVE>CVE-2023-52708</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Do not use WQ_MEM_RECLAIM flag for workqueue

When both ice and the irdma driver are loaded, a warning in
check_flush_dependency is being triggered. This is due to ice driver
workqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma one
is not.

According to kernel documentation, this flag should be set if the
workqueue will be involved in the kernel's memory reclamation flow.
Since it is not, there is no need for the ice driver's WQ to have this
flag set so remove it.

Example trace:

[  +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0
[  +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0
[  +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha
in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel
_rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1
0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_
core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs
ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter
acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba
ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse
[  +0.000161]  [last unloaded: bonding]
[  +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S                 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1
[  +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020
[  +0.000003] Workqueue: ice ice_service_task [ice]
[  +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0
[  +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08
9f e8 bb d3 07 01 &lt;0f&gt; 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06
[  +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282
[  +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000
[  +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80
[  +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112
[  +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000
[  +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400
[  +0.000004] FS:  0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000
[  +0.000003] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0
[  +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  +0.000002] PKRU: 55555554
[  +0.000003] Call Trace:
[  +0.000002]  &lt;TASK&gt;
[  +0.000003]  __flush_workqueue+0x203/0x840
[  +0.000006]  ? mutex_unlock+0x84/0xd0
[  +0.000008]  ? __pfx_mutex_unlock+0x10/0x10
[  +0.000004]  ? __pfx___flush_workqueue+0x10/0x10
[  +0.000006]  ? mutex_lock+0xa3/0xf0
[  +0.000005]  ib_cache_cleanup_one+0x39/0x190 [ib_core]
[  +0.000174]  __ib_unregister_device+0x84/0xf0 [ib_core]
[  +0.000094]  ib_unregister_device+0x25/0x30 [ib_core]
[  +0.000093]  irdma_ib_unregister_device+0x97/0xc0 [irdma]
[  +0.000064]  ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma]
[  +0.000059]  ? up_write+0x5c/0x90
[  +0.000005]  irdma_remove+0x36/0x90 [irdma]
[  +0.000062]  auxiliary_bus_remove+0x32/0x50
[  +0.000007]  device_r
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-52743</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

tcp: do not accept ACK of bytes we never sent

This patch is based on a detailed report and ideas from Yepeng Pan
and Christian Rossow.

ACK seq validation is currently following RFC 5961 5.2 guidelines:

   The ACK value is considered acceptable only if
   it is in the range of ((SND.UNA - MAX.SND.WND) &lt;= SEG.ACK &lt;=
   SND.NXT).  All incoming segments whose ACK value doesn't satisfy the
   above condition MUST be discarded and an ACK sent back.  It needs to
   be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a
   duplicate (SEG.ACK &lt; SND.UNA), it can be ignored.  If the ACK
   acknowledges something not yet sent (SEG.ACK &gt; SND.NXT) then send an
   ACK, drop the segment, and return".  The "ignored" above implies that
   the processing of the incoming data segment continues, which means
   the ACK value is treated as acceptable.  This mitigation makes the
   ACK check more stringent since any ACK &lt; SND.UNA wouldn't be
   accepted, instead only ACKs that are in the range ((SND.UNA -
   MAX.SND.WND) &lt;= SEG.ACK &lt;= SND.NXT) get through.

This can be refined for new (and possibly spoofed) flows,
by not accepting ACK for bytes that were never sent.

This greatly improves TCP security at a little cost.

I added a Fixes: tag to make sure this patch will reach stable trees,
even if the 'blamed' patch was adhering to the RFC.

tp-&gt;bytes_acked was added in linux-4.2

Following packetdrill test (courtesy of Yepeng Pan) shows
the issue at hand:

0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1024) = 0

// ---------------- Handshake ------------------- //

// when window scale is set to 14 the window size can be extended to
// 65535 * (2^14) = 1073725440. Linux would accept an ACK packet
// with ack number in (Server_ISN+1-1073725440. Server_ISN+1)
// ,though this ack number acknowledges some data never
// sent by the server.

+0 &lt; S 0:0(0) win 65535 &lt;mss 1400,nop,wscale 14&gt;
+0 &gt; S. 0:0(0) ack 1 &lt;...&gt;
+0 &lt; . 1:1(0) ack 1 win 65535
+0 accept(3, ..., ...) = 4

// For the established connection, we send an ACK packet,
// the ack packet uses ack number 1 - 1073725300 + 2^32,
// where 2^32 is used to wrap around.
// Note: we used 1073725300 instead of 1073725440 to avoid possible
// edge cases.
// 1 - 1073725300 + 2^32 = 3221241997

// Oops, old kernels happily accept this packet.
+0 &lt; . 1:1001(1000) ack 3221241997 win 65535

// After the kernel fix the following will be replaced by a challenge ACK,
// and prior malicious frame would be dropped.
+0 &gt; . 1:1(0) ack 1001</Note>
    </Notes>
    <CVE>CVE-2023-52881</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

SUNRPC: Fix UAF in svc_tcp_listen_data_ready()

After the listener svc_sock is freed, and before invoking svc_tcp_accept()
for the established child sock, there is a window that the newsock
retaining a freed listener svc_sock in sk_user_data which cloning from
parent. In the race window, if data is received on the newsock, we will
observe use-after-free report in svc_tcp_listen_data_ready().

Reproduce by two tasks:

1. while :; do rpc.nfsd 0 ; rpc.nfsd; done
2. while :; do echo "" | ncat -4 127.0.0.1 2049 ; done

KASAN report:

  ==================================================================
  BUG: KASAN: slab-use-after-free in svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc]
  Read of size 8 at addr ffff888139d96228 by task nc/102553
  CPU: 7 PID: 102553 Comm: nc Not tainted 6.3.0+ #18
  Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
  Call Trace:
   &lt;IRQ&gt;
   dump_stack_lvl+0x33/0x50
   print_address_description.constprop.0+0x27/0x310
   print_report+0x3e/0x70
   kasan_report+0xae/0xe0
   svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc]
   tcp_data_queue+0x9f4/0x20e0
   tcp_rcv_established+0x666/0x1f60
   tcp_v4_do_rcv+0x51c/0x850
   tcp_v4_rcv+0x23fc/0x2e80
   ip_protocol_deliver_rcu+0x62/0x300
   ip_local_deliver_finish+0x267/0x350
   ip_local_deliver+0x18b/0x2d0
   ip_rcv+0x2fb/0x370
   __netif_receive_skb_one_core+0x166/0x1b0
   process_backlog+0x24c/0x5e0
   __napi_poll+0xa2/0x500
   net_rx_action+0x854/0xc90
   __do_softirq+0x1bb/0x5de
   do_softirq+0xcb/0x100
   &lt;/IRQ&gt;
   &lt;TASK&gt;
   ...
   &lt;/TASK&gt;

  Allocated by task 102371:
   kasan_save_stack+0x1e/0x40
   kasan_set_track+0x21/0x30
   __kasan_kmalloc+0x7b/0x90
   svc_setup_socket+0x52/0x4f0 [sunrpc]
   svc_addsock+0x20d/0x400 [sunrpc]
   __write_ports_addfd+0x209/0x390 [nfsd]
   write_ports+0x239/0x2c0 [nfsd]
   nfsctl_transaction_write+0xac/0x110 [nfsd]
   vfs_write+0x1c3/0xae0
   ksys_write+0xed/0x1c0
   do_syscall_64+0x38/0x90
   entry_SYSCALL_64_after_hwframe+0x72/0xdc

  Freed by task 102551:
   kasan_save_stack+0x1e/0x40
   kasan_set_track+0x21/0x30
   kasan_save_free_info+0x2a/0x50
   __kasan_slab_free+0x106/0x190
   __kmem_cache_free+0x133/0x270
   svc_xprt_free+0x1e2/0x350 [sunrpc]
   svc_xprt_destroy_all+0x25a/0x440 [sunrpc]
   nfsd_put+0x125/0x240 [nfsd]
   nfsd_svc+0x2cb/0x3c0 [nfsd]
   write_threads+0x1ac/0x2a0 [nfsd]
   nfsctl_transaction_write+0xac/0x110 [nfsd]
   vfs_write+0x1c3/0xae0
   ksys_write+0xed/0x1c0
   do_syscall_64+0x38/0x90
   entry_SYSCALL_64_after_hwframe+0x72/0xdc

Fix the UAF by simply doing nothing in svc_tcp_listen_data_ready()
if state != TCP_LISTEN, that will avoid dereferencing svsk for all
child socket.</Note>
    </Notes>
    <CVE>CVE-2023-52885</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

gsmi: fix null-deref in gsmi_get_variable

We can get EFI variables without fetching the attribute, so we must
allow for that in gsmi.

commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore
access layer") added a new get_variable call with attr=NULL, which
triggers panic in gsmi.</Note>
    </Notes>
    <CVE>CVE-2023-52893</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xhci: Fix null pointer dereference when host dies

Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race
and cause null pointer dereference when host suddenly dies.

Usb core may call xhci_free_dev() which frees the xhci-&gt;devs[slot_id]
virt device at the same time that xhci_kill_endpoint_urbs() tries to
loop through all the device's endpoints, checking if there are any
cancelled urbs left to give back.

hold the xhci spinlock while freeing the virt device</Note>
    </Notes>
    <CVE>CVE-2023-52898</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: xhci: Check endpoint is valid before dereferencing it

When the host controller is not responding, all URBs queued to all
endpoints need to be killed. This can cause a kernel panic if we
dereference an invalid endpoint.

Fix this by using xhci_get_virt_ep() helper to find the endpoint and
checking if the endpoint is valid before dereferencing it.

[233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead
[233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8

[233311.853964] pc : xhci_hc_died+0x10c/0x270
[233311.853971] lr : xhci_hc_died+0x1ac/0x270

[233311.854077] Call trace:
[233311.854085]  xhci_hc_died+0x10c/0x270
[233311.854093]  xhci_stop_endpoint_command_watchdog+0x100/0x1a4
[233311.854105]  call_timer_fn+0x50/0x2d4
[233311.854112]  expire_timers+0xac/0x2e4
[233311.854118]  run_timer_softirq+0x300/0xabc
[233311.854127]  __do_softirq+0x148/0x528
[233311.854135]  irq_exit+0x194/0x1a8
[233311.854143]  __handle_domain_irq+0x164/0x1d0
[233311.854149]  gic_handle_irq.22273+0x10c/0x188
[233311.854156]  el1_irq+0xfc/0x1a8
[233311.854175]  lpm_cpuidle_enter+0x25c/0x418 [msm_pm]
[233311.854185]  cpuidle_enter_state+0x1f0/0x764
[233311.854194]  do_idle+0x594/0x6ac
[233311.854201]  cpu_startup_entry+0x7c/0x80
[233311.854209]  secondary_start_kernel+0x170/0x198</Note>
    </Notes>
    <CVE>CVE-2023-52901</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pn533: Wait for out_urb's completion in pn533_usb_send_frame()

Fix a use-after-free that occurs in hcd when in_urb sent from
pn533_usb_send_frame() is completed earlier than out_urb. Its callback
frees the skb data in pn533_send_async_complete() that is used as a
transfer buffer of out_urb. Wait before sending in_urb until the
callback of out_urb is called. To modify the callback of out_urb alone,
separate the complete function of out_urb and ack_urb.

Found by a modified version of syzkaller.

BUG: KASAN: use-after-free in dummy_timer
Call Trace:
 memcpy (mm/kasan/shadow.c:65)
 dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352)
 transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453)
 dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972)
 arch_static_branch (arch/x86/include/asm/jump_label.h:27)
 static_key_false (include/linux/jump_label.h:207)
 timer_expire_exit (include/trace/events/timer.h:127)
 call_timer_fn (kernel/time/timer.c:1475)
 expire_timers (kernel/time/timer.c:1519)
 __run_timers (kernel/time/timer.c:1790)
 run_timer_softirq (kernel/time/timer.c:1803)</Note>
    </Notes>
    <CVE>CVE-2023-52907</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xfer

In af9035_i2c_master_xfer, msg is controlled by user. When msg[i].buf
is null and msg[i].len is zero, former checks on msg[i].buf would be
passed. Malicious data finally reach af9035_i2c_master_xfer. If accessing
msg[i].buf[0] without sanity check, null ptr deref would happen.
We add check on msg[i].len to prevent crash.

Similar commit:
commit 0ed554fd769a
("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")</Note>
    </Notes>
    <CVE>CVE-2023-52915</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pci: cx23885: check cx23885_vdev_init() return

cx23885_vdev_init() can return a NULL pointer, but that pointer
is used in the next line without a check.

Add a NULL pointer check and go to the error unwind if it is NULL.</Note>
    </Notes>
    <CVE>CVE-2023-52918</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In affected libpcap versions during the setup of a remote packet capture the internal function sock_initaddress() calls getaddrinfo() and possibly freeaddrinfo(), but does not clearly indicate to the caller function whether freeaddrinfo() still remains to be called after the function returns.  This makes it possible in some scenarios that both the function and its caller call freeaddrinfo() for the same allocated memory block.  A similar problem was reported in Apple libpcap, to which Apple assigned CVE-2023-40400.</Note>
    </Notes>
    <CVE>CVE-2023-7256</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libpcap1-1.8.1-10.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">When asked to both use a `.netrc` file for credentials and to follow HTTP
redirects, curl could leak the password used for the first host to the
followed-to host under certain circumstances.

This flaw only manifests itself if the netrc file has an entry that matches
the redirect target hostname but the entry either omits just the password or
omits both login and password.</Note>
    </Notes>
    <CVE>CVE-2024-11053</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:curl-8.0.1-11.101.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libcurl4-8.0.1-11.101.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The urllib.parse.urlsplit() and urlparse() functions improperly validated bracketed hosts (`[]`), allowing hosts that weren't IPv6 or IPvFuture. This behavior was not conformant to RFC 3986 and potentially enabled SSRF if a URL is processed by more than one URL parser.</Note>
    </Notes>
    <CVE>CVE-2024-11168</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libpython2_7-1_0-2.7.18-33.38.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libpython3_4m1_0-3.4.10-25.145.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python-2.7.18-33.38.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python-base-2.7.18-33.38.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python-xml-2.7.18-33.38.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-3.4.10-25.145.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-base-3.4.10-25.145.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">Resolver caches and authoritative zone databases that hold significant numbers of RRs for the same hostname (of any RTYPE) can suffer from degraded performance as content is being added or updated, and also when handling client queries for this name.
This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.4-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1.</Note>
    </Notes>
    <CVE>CVE-2024-1737</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:bind-utils-9.11.22-3.57.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libbind9-161-9.11.22-3.57.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libdns1110-9.11.22-3.57.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libirs161-9.11.22-3.57.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libisc1107-9.11.22-3.57.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libisccc161-9.11.22-3.57.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libisccfg163-9.11.22-3.57.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:liblwres161-9.11.22-3.57.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python-bind-9.11.22-3.57.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">If a server hosts a zone containing a "KEY" Resource Record, or a resolver DNSSEC-validates a "KEY" Resource Record from a DNSSEC-signed domain in cache, a client can exhaust resolver CPU resources by sending a stream of SIG(0) signed requests.
This issue affects BIND 9 versions 9.0.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.49-S1, and 9.18.11-S1 through 9.18.27-S1.</Note>
    </Notes>
    <CVE>CVE-2024-1975</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:bind-utils-9.11.22-3.57.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libbind9-161-9.11.22-3.57.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libdns1110-9.11.22-3.57.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libirs161-9.11.22-3.57.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libisc1107-9.11.22-3.57.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libisccc161-9.11.22-3.57.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libisccfg163-9.11.22-3.57.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:liblwres161-9.11.22-3.57.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python-bind-9.11.22-3.57.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/smc: fix illegal rmb_desc access in SMC-D connection dump

A crash was found when dumping SMC-D connections. It can be reproduced
by following steps:

- run nginx/wrk test:
  smc_run nginx
  smc_run wrk -t 16 -c 1000 -d &lt;duration&gt; -H 'Connection: Close' &lt;URL&gt;

- continuously dump SMC-D connections in parallel:
  watch -n 1 'smcss -D'

 BUG: kernel NULL pointer dereference, address: 0000000000000030
 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G	E      6.7.0+ #55
 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
 Call Trace:
  &lt;TASK&gt;
  ? __die+0x24/0x70
  ? page_fault_oops+0x66/0x150
  ? exc_page_fault+0x69/0x140
  ? asm_exc_page_fault+0x26/0x30
  ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
  ? __kmalloc_node_track_caller+0x35d/0x430
  ? __alloc_skb+0x77/0x170
  smc_diag_dump_proto+0xd0/0xf0 [smc_diag]
  smc_diag_dump+0x26/0x60 [smc_diag]
  netlink_dump+0x19f/0x320
  __netlink_dump_start+0x1dc/0x300
  smc_diag_handler_dump+0x6a/0x80 [smc_diag]
  ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag]
  sock_diag_rcv_msg+0x121/0x140
  ? __pfx_sock_diag_rcv_msg+0x10/0x10
  netlink_rcv_skb+0x5a/0x110
  sock_diag_rcv+0x28/0x40
  netlink_unicast+0x22a/0x330
  netlink_sendmsg+0x1f8/0x420
  __sock_sendmsg+0xb0/0xc0
  ____sys_sendmsg+0x24e/0x300
  ? copy_msghdr_from_user+0x62/0x80
  ___sys_sendmsg+0x7c/0xd0
  ? __do_fault+0x34/0x160
  ? do_read_fault+0x5f/0x100
  ? do_fault+0xb0/0x110
  ? __handle_mm_fault+0x2b0/0x6c0
  __sys_sendmsg+0x4d/0x80
  do_syscall_64+0x69/0x180
  entry_SYSCALL_64_after_hwframe+0x6e/0x76

It is possible that the connection is in process of being established
when we dump it. Assumed that the connection has been registered in a
link group by smc_conn_create() but the rmb_desc has not yet been
initialized by smc_buf_create(), thus causing the illegal access to
conn-&gt;rmb_desc. So fix it by checking before dump.</Note>
    </Notes>
    <CVE>CVE-2024-26615</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xhci: handle isoc Babble and Buffer Overrun events properly

xHCI 4.9 explicitly forbids assuming that the xHC has released its
ownership of a multi-TRB TD when it reports an error on one of the
early TRBs. Yet the driver makes such assumption and releases the TD,
allowing the remaining TRBs to be freed or overwritten by new TDs.

The xHC should also report completion of the final TRB due to its IOC
flag being set by us, regardless of prior errors. This event cannot
be recognized if the TD has already been freed earlier, resulting in
"Transfer event TRB DMA ptr not part of current TD" error message.

Fix this by reusing the logic for processing isoc Transaction Errors.
This also handles hosts which fail to report the final completion.

Fix transfer length reporting on Babble errors. They may be caused by
device malfunction, no guarantee that the buffer has been filled.</Note>
    </Notes>
    <CVE>CVE-2024-26659</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tipc: Check the bearer type before calling tipc_udp_nl_bearer_add()

syzbot reported the following general protection fault [1]:

general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087]
...
RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291
...
Call Trace:
 &lt;TASK&gt;
 tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646
 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089
 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972
 genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline]
 genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067
 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544
 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076
 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
 netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367
 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0xd5/0x180 net/socket.c:745
 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584
 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638
 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

The cause of this issue is that when tipc_nl_bearer_add() is called with
the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called
even if the bearer is not UDP.

tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that
the media_ptr field of the tipc_bearer has an udp_bearer type object, so
the function goes crazy for non-UDP bearers.

This patch fixes the issue by checking the bearer type before calling
tipc_udp_nl_bearer_add() in tipc_nl_bearer_add().</Note>
    </Notes>
    <CVE>CVE-2024-26663</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_limit: reject configurations that cause integer overflow

Reject bogus configs where internal token counter wraps around.
This only occurs with very very large requests, such as 17gbyte/s.

Its better to reject this rather than having incorrect ratelimit.</Note>
    </Notes>
    <CVE>CVE-2024-26668</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipv6: sr: fix possible use-after-free and null-ptr-deref

The pernet operations structure for the subsystem must be registered
before registering the generic netlink family.</Note>
    </Notes>
    <CVE>CVE-2024-26735</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Avoid potential use-after-free in hci_error_reset

While handling the HCI_EV_HARDWARE_ERROR event, if the underlying
BT controller is not responding, the GPIO reset mechanism would
free the hci_dev and lead to a use-after-free in hci_error_reset.

Here's the call trace observed on a ChromeOS device with Intel AX201:
   queue_work_on+0x3e/0x6c
   __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth &lt;HASH:3b4a6&gt;]
   ? init_wait_entry+0x31/0x31
   __hci_cmd_sync+0x16/0x20 [bluetooth &lt;HASH:3b4a 6&gt;]
   hci_error_reset+0x4f/0xa4 [bluetooth &lt;HASH:3b4a 6&gt;]
   process_one_work+0x1d8/0x33f
   worker_thread+0x21b/0x373
   kthread+0x13a/0x152
   ? pr_cont_work+0x54/0x54
   ? kthread_blkcg+0x31/0x31
    ret_from_fork+0x1f/0x30

This patch holds the reference count on the hci_dev while processing
a HCI_EV_HARDWARE_ERROR event to avoid potential crash.</Note>
    </Notes>
    <CVE>CVE-2024-26801</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: prevent perpetual headroom growth

syzkaller triggered following kasan splat:
BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191
[..]
 kasan_report+0xda/0x110 mm/kasan/report.c:588
 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline]
 ___skb_get_hash net/core/flow_dissector.c:1791 [inline]
 __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856
 skb_get_hash include/linux/skbuff.h:1556 [inline]
 ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748
 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308
 __netdev_start_xmit include/linux/netdevice.h:4940 [inline]
 netdev_start_xmit include/linux/netdevice.h:4954 [inline]
 xmit_one net/core/dev.c:3548 [inline]
 dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564
 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349
 dev_queue_xmit include/linux/netdevice.h:3134 [inline]
 neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592
 ...
 ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235
 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323
 ..
 iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82
 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831
 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665
 __netdev_start_xmit include/linux/netdevice.h:4940 [inline]
 netdev_start_xmit include/linux/netdevice.h:4954 [inline]
 xmit_one net/core/dev.c:3548 [inline]
 dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564
 ...

The splat occurs because skb-&gt;data points past skb-&gt;head allocated area.
This is because neigh layer does:
  __skb_pull(skb, skb_network_offset(skb));

... but skb_network_offset() returns a negative offset and __skb_pull()
arg is unsigned.  IOW, we skb-&gt;data gets "adjusted" by a huge value.

The negative value is returned because skb-&gt;head and skb-&gt;data distance is
more than 64k and skb-&gt;network_header (u16) has wrapped around.

The bug is in the ip_tunnel infrastructure, which can cause
dev-&gt;needed_headroom to increment ad infinitum.

The syzkaller reproducer consists of packets getting routed via a gre
tunnel, and route of gre encapsulated packets pointing at another (ipip)
tunnel.  The ipip encapsulation finds gre0 as next output device.

This results in the following pattern:

1). First packet is to be sent out via gre0.
Route lookup found an output device, ipip0.

2).
ip_tunnel_xmit for gre0 bumps gre0-&gt;needed_headroom based on the future
output device, rt.dev-&gt;needed_headroom (ipip0).

3).
ip output / start_xmit moves skb on to ipip0. which runs the same
code path again (xmit recursion).

4).
Routing step for the post-gre0-encap packet finds gre0 as output device
to use for ipip0 encapsulated packet.

tunl0-&gt;needed_headroom is then incremented based on the (already bumped)
gre0 device headroom.

This repeats for every future packet:

gre0-&gt;needed_headroom gets inflated because previous packets' ipip0 step
incremented rt-&gt;dev (gre0) headroom, and ipip0 incremented because gre0
needed_headroom was increased.

For each subsequent packet, gre/ipip0-&gt;needed_headroom grows until
post-expand-head reallocations result in a skb-&gt;head/data distance of
more than 64k.

Once that happens, skb-&gt;network_header (u16) wraps around when
pskb_expand_head tries to make sure that skb_network_offset() is unchanged
after the headroom expansion/reallocation.

After this skb_network_offset(skb) returns a different (and negative)
result post headroom expansion.

The next trip to neigh layer (or anything else that would __skb_pull the
network header) makes skb-&gt;data point to a memory location outside
skb-&gt;head area.

v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to
prevent perpetual increase instead of dropping the headroom increment
completely.</Note>
    </Notes>
    <CVE>CVE-2024-26804</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vfio/pci: Create persistent INTx handler

A vulnerability exists where the eventfd for INTx signaling can be
deconfigured, which unregisters the IRQ handler but still allows
eventfds to be signaled with a NULL context through the SET_IRQS ioctl
or through unmask irqfd if the device interrupt is pending.

Ideally this could be solved with some additional locking; the igate
mutex serializes the ioctl and config space accesses, and the interrupt
handler is unregistered relative to the trigger, but the irqfd path
runs asynchronous to those.  The igate mutex cannot be acquired from the
atomic context of the eventfd wake function.  Disabling the irqfd
relative to the eventfd registration is potentially incompatible with
existing userspace.

As a result, the solution implemented here moves configuration of the
INTx interrupt handler to track the lifetime of the INTx context object
and irq_type configuration, rather than registration of a particular
trigger eventfd.  Synchronization is added between the ioctl path and
eventfd_signal() wrapper such that the eventfd trigger can be
dynamically updated relative to in-flight interrupts or irqfd callbacks.</Note>
    </Notes>
    <CVE>CVE-2024-26812</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_conntrack_h323: Add protection for bmp length out of range

UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts
that are out of bounds for their data type.

vmlinux   get_bitmap(b=75) + 712
&lt;net/netfilter/nf_conntrack_h323_asn1.c:0&gt;
vmlinux   decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956
&lt;net/netfilter/nf_conntrack_h323_asn1.c:592&gt;
vmlinux   decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216
&lt;net/netfilter/nf_conntrack_h323_asn1.c:814&gt;
vmlinux   decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812
&lt;net/netfilter/nf_conntrack_h323_asn1.c:576&gt;
vmlinux   decode_choice(base=0xFFFFFFD008037280, level=0) + 1216
&lt;net/netfilter/nf_conntrack_h323_asn1.c:814&gt;
vmlinux   DecodeRasMessage() + 304
&lt;net/netfilter/nf_conntrack_h323_asn1.c:833&gt;
vmlinux   ras_help() + 684
&lt;net/netfilter/nf_conntrack_h323_main.c:1728&gt;
vmlinux   nf_confirm() + 188
&lt;net/netfilter/nf_conntrack_proto.c:137&gt;

Due to abnormal data in skb-&gt;data, the extension bitmap length
exceeds 32 when decoding ras message then uses the length to make
a shift operation. It will change into negative after several loop.
UBSAN load could detect a negative shift as an undefined behaviour
and reports exception.
So we add the protection to avoid the length exceeding 32. Or else
it will return out of range error and stop decoding.</Note>
    </Notes>
    <CVE>CVE-2024-26851</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: af_bluetooth: Fix deadlock

Attemting to do sock_lock on .recvmsg may cause a deadlock as shown
bellow, so instead of using sock_sock this uses sk_receive_queue.lock
on bt_sock_ioctl to avoid the UAF:

INFO: task kworker/u9:1:121 blocked for more than 30 seconds.
      Not tainted 6.7.6-lemon #183
Workqueue: hci0 hci_rx_work
Call Trace:
 &lt;TASK&gt;
 __schedule+0x37d/0xa00
 schedule+0x32/0xe0
 __lock_sock+0x68/0xa0
 ? __pfx_autoremove_wake_function+0x10/0x10
 lock_sock_nested+0x43/0x50
 l2cap_sock_recv_cb+0x21/0xa0
 l2cap_recv_frame+0x55b/0x30a0
 ? psi_task_switch+0xeb/0x270
 ? finish_task_switch.isra.0+0x93/0x2a0
 hci_rx_work+0x33a/0x3f0
 process_one_work+0x13a/0x2f0
 worker_thread+0x2f0/0x410
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe0/0x110
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2c/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-26886</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tracing/trigger: Fix to return error if failed to alloc snapshot

Fix register_snapshot_trigger() to return error code if it failed to
allocate a snapshot instead of 0 (success). Unless that, it will register
snapshot trigger without an error.</Note>
    </Notes>
    <CVE>CVE-2024-26920</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_set_pipapo: do not free live element

Pablo reports a crash with large batches of elements with a
back-to-back add/remove pattern.  Quoting Pablo:

  add_elem("00000000") timeout 100 ms
  ...
  add_elem("0000000X") timeout 100 ms
  del_elem("0000000X") &lt;---------------- delete one that was just added
  ...
  add_elem("00005000") timeout 100 ms

  1) nft_pipapo_remove() removes element 0000000X
  Then, KASAN shows a splat.

Looking at the remove function there is a chance that we will drop a
rule that maps to a non-deactivated element.

Removal happens in two steps, first we do a lookup for key k and return the
to-be-removed element and mark it as inactive in the next generation.
Then, in a second step, the element gets removed from the set/map.

The _remove function does not work correctly if we have more than one
element that share the same key.

This can happen if we insert an element into a set when the set already
holds an element with same key, but the element mapping to the existing
key has timed out or is not active in the next generation.

In such case its possible that removal will unmap the wrong element.
If this happens, we will leak the non-deactivated element, it becomes
unreachable.

The element that got deactivated (and will be freed later) will
remain reachable in the set data structure, this can result in
a crash when such an element is retrieved during lookup (stale
pointer).

Add a check that the fully matching key does in fact map to the element
that we have marked as inactive in the deactivation step.
If not, we need to continue searching.

Add a bug/warn trap at the end of the function as well, the remove
function must not ever be called with an invisible/unreachable/non-existent
element.

v2: avoid uneeded temporary variable (Stefano)</Note>
    </Notes>
    <CVE>CVE-2024-26924</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 memleak in map from abort path

The delete set command does not rely on the transaction object for
element removal, therefore, a combination of delete element + delete set
from the abort path could result in restoring twice the refcount of the
mapping.

Check for inactive element in the next generation for the delete element
command in the abort path, skip restoring state if next generation bit
has been already cleared. This is similar to the activate logic using
the set walk iterator.

[ 6170.286929] ------------[ cut here ]------------
[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.287071] Modules linked in: [...]
[ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365
[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 &lt;0f&gt; 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f
[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202
[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000
[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750
[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55
[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10
[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100
[ 6170.287940] FS:  0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000
[ 6170.287948] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0
[ 6170.287962] Call Trace:
[ 6170.287967]  &lt;TASK&gt;
[ 6170.287973]  ? __warn+0x9f/0x1a0
[ 6170.287986]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288092]  ? report_bug+0x1b1/0x1e0
[ 6170.287986]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288092]  ? report_bug+0x1b1/0x1e0
[ 6170.288104]  ? handle_bug+0x3c/0x70
[ 6170.288112]  ? exc_invalid_op+0x17/0x40
[ 6170.288120]  ? asm_exc_invalid_op+0x1a/0x20
[ 6170.288132]  ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]
[ 6170.288243]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288366]  ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]
[ 6170.288483]  nf_tables_trans_destroy_work+0x588/0x590 [nf_tables]</Note>
    </Notes>
    <CVE>CVE-2024-27011</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential data-race in __nft_obj_type_get()

nft_unregister_obj() can concurrent with __nft_obj_type_get(),
and there is not any protection when iterate over nf_tables_objects
list in __nft_obj_type_get(). Therefore, there is potential data-race
of nf_tables_objects list entry.

Use list_for_each_entry_rcu() to iterate over nf_tables_objects
list in __nft_obj_type_get(), and use rcu_read_lock() in the caller
nft_obj_type_get() to protect the entire type query process.</Note>
    </Notes>
    <CVE>CVE-2024-27019</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential data-race in __nft_expr_type_get()

nft_unregister_expr() can concurrent with __nft_expr_type_get(),
and there is not any protection when iterate over nf_tables_expressions
list in __nft_expr_type_get(). Therefore, there is potential data-race
of nf_tables_expressions list entry.

Use list_for_each_entry_rcu() to iterate over nf_tables_expressions
list in __nft_expr_type_get(), and use rcu_read_lock() in the caller
nft_expr_type_get() to protect the entire type query process.</Note>
    </Notes>
    <CVE>CVE-2024-27020</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nbd: null check for nla_nest_start

nla_nest_start() may fail and return NULL. Insert a check and set errno
based on other call sites within the same source code.</Note>
    </Notes>
    <CVE>CVE-2024-27025</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value

cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it
and return 0 in case of error.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-27051</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vfio/pci: Disable auto-enable of exclusive INTx IRQ

Currently for devices requiring masking at the irqchip for INTx, ie.
devices without DisINTx support, the IRQ is enabled in request_irq()
and subsequently disabled as necessary to align with the masked status
flag.  This presents a window where the interrupt could fire between
these events, resulting in the IRQ incrementing the disable depth twice.
This would be unrecoverable for a user since the masked flag prevents
nested enables through vfio.

Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx
is never auto-enabled, then unmask as required.</Note>
    </Notes>
    <CVE>CVE-2024-27437</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fsl: qbman: Use raw spinlock for cgr_lock

smp_call_function always runs its callback in hard IRQ context, even on
PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock
for cgr_lock to ensure we aren't waiting on a sleeping task.

Although this bug has existed for a while, it was not apparent until
commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change")
which invokes smp_call_function_single via qman_update_cgr_safe every
time a link goes up or down.</Note>
    </Notes>
    <CVE>CVE-2024-35819</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: mvpp2: clear BM pool before initialization

Register value persist after booting the kernel using
kexec which results in kernel panic. Thus clear the
BM pool registers before initialisation to fix the issue.</Note>
    </Notes>
    <CVE>CVE-2024-35837</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ax25: fix use-after-free bugs caused by ax25_ds_del_timer

When the ax25 device is detaching, the ax25_dev_device_down()
calls ax25_ds_del_timer() to cleanup the slave_timer. When
the timer handler is running, the ax25_ds_del_timer() that
calls del_timer() in it will return directly. As a result,
the use-after-free bugs could happen, one of the scenarios
is shown below:

      (Thread 1)          |      (Thread 2)
                          | ax25_ds_timeout()
ax25_dev_device_down()    |
  ax25_ds_del_timer()     |
    del_timer()           |
  ax25_dev_put() //FREE   |
                          |  ax25_dev-&gt; //USE

In order to mitigate bugs, when the device is detaching, use
timer_shutdown_sync() to stop the timer.</Note>
    </Notes>
    <CVE>CVE-2024-35887</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: act_skbmod: prevent kernel-infoleak

syzbot found that tcf_skbmod_dump() was copying four bytes
from kernel stack to user space [1].

The issue here is that 'struct tc_skbmod' has a four bytes hole.

We need to clear the structure before filling fields.

[1]
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
 BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
 BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
 BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
 BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
 BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
  instrument_copy_to_user include/linux/instrumented.h:114 [inline]
  copy_to_user_iter lib/iov_iter.c:24 [inline]
  iterate_ubuf include/linux/iov_iter.h:29 [inline]
  iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
  iterate_and_advance include/linux/iov_iter.h:271 [inline]
  _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
  copy_to_iter include/linux/uio.h:196 [inline]
  simple_copy_to_iter net/core/datagram.c:532 [inline]
  __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420
  skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
  skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]
  netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962
  sock_recvmsg_nosec net/socket.c:1046 [inline]
  sock_recvmsg+0x2c4/0x340 net/socket.c:1068
  __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242
  __do_sys_recvfrom net/socket.c:2260 [inline]
  __se_sys_recvfrom net/socket.c:2256 [inline]
  __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

Uninit was stored to memory at:
  pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253
  netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317
  netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351
  nlmsg_unicast include/net/netlink.h:1144 [inline]
  nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610
  rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741
  rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]
  tcf_add_notify net/sched/act_api.c:2048 [inline]
  tcf_action_add net/sched/act_api.c:2071 [inline]
  tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119
  rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
  netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559
  rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613
  netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
  netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361
  netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:745
  ____sys_sendmsg+0x877/0xb60 net/socket.c:2584
  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
  __sys_sendmsg net/socket.c:2667 [inline]
  __do_sys_sendmsg net/socket.c:2676 [inline]
  __se_sys_sendmsg net/socket.c:2674 [inline]
  __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

Uninit was stored to memory at:
  __nla_put lib/nlattr.c:1041 [inline]
  nla_put+0x1c6/0x230 lib/nlattr.c:1099
  tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256
  tcf_action_dump_old net/sched/act_api.c:1191 [inline]
  tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227
  tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251
  tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628
  tcf_add_notify_msg net/sched/act_api.c:2023 [inline]
  tcf_add_notify net/sched/act_api.c:2042 [inline]
  tcf_action_add net/sched/act_api.c:2071 [inline]
  tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119
  rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
  netlink_rcv_skb+0x375/0x650 net/netlink/af_netli
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-35893</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix uninit-value in nci_dev_up and nci_ntf_packet

syzbot reported the following uninit-value access issue [1][2]:

nci_rx_work() parses and processes received packet. When the payload
length is zero, each message type handler reads uninitialized payload
and KMSAN detects this issue. The receipt of a packet with a zero-size
payload is considered unexpected, and therefore, such packets should be
silently discarded.

This patch resolved this issue by checking payload size before calling
each message type handler codes.</Note>
    </Notes>
    <CVE>CVE-2024-35915</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btintel: Fix null ptr deref in btintel_read_version

If hci_cmd_sync_complete() is triggered and skb is NULL, then
hdev-&gt;req_skb is NULL, which will cause this issue.</Note>
    </Notes>
    <CVE>CVE-2024-35933</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: check A-MSDU format more carefully

If it looks like there's another subframe in the A-MSDU
but the header isn't fully there, we can end up reading
data out of bounds, only to discard later. Make this a
bit more careful and check if the subframe header can
even be present.</Note>
    </Notes>
    <CVE>CVE-2024-35937</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

btrfs: make sure that WRITTEN is set on all metadata blocks

We previously would call btrfs_check_leaf() if we had the check
integrity code enabled, which meant that we could only run the extended
leaf checks if we had WRITTEN set on the header flags.

This leaves a gap in our checking, because we could end up with
corruption on disk where WRITTEN isn't set on the leaf, and then the
extended leaf checks don't get run which we rely on to validate all of
the item pointers to make sure we don't access memory outside of the
extent buffer.

However, since 732fab95abe2 ("btrfs: check-integrity: remove
CONFIG_BTRFS_FS_CHECK_INTEGRITY option") we no longer call
btrfs_check_leaf() from btrfs_mark_buffer_dirty(), which means we only
ever call it on blocks that are being written out, and thus have WRITTEN
set, or that are being read in, which should have WRITTEN set.

Add checks to make sure we have WRITTEN set appropriately, and then make
sure __btrfs_check_leaf() always does the item checking.  This will
protect us from file systems that have been corrupted and no longer have
WRITTEN set on some of the blocks.

This was hit on a crafted image tweaking the WRITTEN bit and reported by
KASAN as out-of-bound access in the eb accessors. The example is a dir
item at the end of an eb.

  [2.042] BTRFS warning (device loop1): bad eb member start: ptr 0x3fff start 30572544 member offset 16410 size 2
  [2.040] general protection fault, probably for non-canonical address 0xe0009d1000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI
  [2.537] KASAN: maybe wild-memory-access in range [0x0005088000000018-0x000508800000001f]
  [2.729] CPU: 0 PID: 2587 Comm: mount Not tainted 6.8.2 #1
  [2.729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  [2.621] RIP: 0010:btrfs_get_16+0x34b/0x6d0
  [2.621] RSP: 0018:ffff88810871fab8 EFLAGS: 00000206
  [2.621] RAX: 0000a11000000003 RBX: ffff888104ff8720 RCX: ffff88811b2288c0
  [2.621] RDX: dffffc0000000000 RSI: ffffffff81dd8aca RDI: ffff88810871f748
  [2.621] RBP: 000000000000401a R08: 0000000000000001 R09: ffffed10210e3ee9
  [2.621] R10: ffff88810871f74f R11: 205d323430333737 R12: 000000000000001a
  [2.621] R13: 000508800000001a R14: 1ffff110210e3f5d R15: ffffffff850011e8
  [2.621] FS:  00007f56ea275840(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000
  [2.621] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [2.621] CR2: 00007febd13b75c0 CR3: 000000010bb50000 CR4: 00000000000006f0
  [2.621] Call Trace:
  [2.621]  &lt;TASK&gt;
  [2.621]  ? show_regs+0x74/0x80
  [2.621]  ? die_addr+0x46/0xc0
  [2.621]  ? exc_general_protection+0x161/0x2a0
  [2.621]  ? asm_exc_general_protection+0x26/0x30
  [2.621]  ? btrfs_get_16+0x33a/0x6d0
  [2.621]  ? btrfs_get_16+0x34b/0x6d0
  [2.621]  ? btrfs_get_16+0x33a/0x6d0
  [2.621]  ? __pfx_btrfs_get_16+0x10/0x10
  [2.621]  ? __pfx_mutex_unlock+0x10/0x10
  [2.621]  btrfs_match_dir_item_name+0x101/0x1a0
  [2.621]  btrfs_lookup_dir_item+0x1f3/0x280
  [2.621]  ? __pfx_btrfs_lookup_dir_item+0x10/0x10
  [2.621]  btrfs_get_tree+0xd25/0x1910

[ copy more details from report ]</Note>
    </Notes>
    <CVE>CVE-2024-35949</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix not validating setsockopt user input

Check user input length before copying data.</Note>
    </Notes>
    <CVE>CVE-2024-35965</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: RFCOMM: Fix not validating setsockopt user input

syzbot reported rfcomm_sock_setsockopt_old() is copying data without
checking user input length.

BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset
include/linux/sockptr.h:49 [inline]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr
include/linux/sockptr.h:55 [inline]
BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old
net/bluetooth/rfcomm/sock.c:632 [inline]
BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70
net/bluetooth/rfcomm/sock.c:673
Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064</Note>
    </Notes>
    <CVE>CVE-2024-35966</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Fix memory leak in hci_req_sync_complete()

In 'hci_req_sync_complete()', always free the previous sync
request state before assigning reference to a new one.</Note>
    </Notes>
    <CVE>CVE-2024-35978</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ACPI: CPPC: Use access_width over bit_width for system memory accesses

To align with ACPI 6.3+, since bit_width can be any 8-bit value, it
cannot be depended on to be always on a clean 8b boundary. This was
uncovered on the Cobalt 100 platform.

SError Interrupt on CPU26, code 0xbe000011 -- SError
 CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1
 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
 pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)
 pc : cppc_get_perf_caps+0xec/0x410
 lr : cppc_get_perf_caps+0xe8/0x410
 sp : ffff8000155ab730
 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078
 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff
 x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000
 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff
 x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008
 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006
 x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec
 x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028
 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff
 x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000
 Kernel panic - not syncing: Asynchronous SError Interrupt
 CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted
5.15.2.1-13 #1
 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
 Call trace:
  dump_backtrace+0x0/0x1e0
  show_stack+0x24/0x30
  dump_stack_lvl+0x8c/0xb8
  dump_stack+0x18/0x34
  panic+0x16c/0x384
  add_taint+0x0/0xc0
  arm64_serror_panic+0x7c/0x90
  arm64_is_fatal_ras_serror+0x34/0xa4
  do_serror+0x50/0x6c
  el1h_64_error_handler+0x40/0x74
  el1h_64_error+0x7c/0x80
  cppc_get_perf_caps+0xec/0x410
  cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]
  cpufreq_online+0x2dc/0xa30
  cpufreq_add_dev+0xc0/0xd4
  subsys_interface_register+0x134/0x14c
  cpufreq_register_driver+0x1b0/0x354
  cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]
  do_one_initcall+0x50/0x250
  do_init_module+0x60/0x27c
  load_module+0x2300/0x2570
  __do_sys_finit_module+0xa8/0x114
  __arm64_sys_finit_module+0x2c/0x3c
  invoke_syscall+0x78/0x100
  el0_svc_common.constprop.0+0x180/0x1a0
  do_el0_svc+0x84/0xa0
  el0_svc+0x2c/0xc0
  el0t_64_sync_handler+0xa4/0x12c
  el0t_64_sync+0x1a4/0x1a8

Instead, use access_width to determine the size and use the offset and
width to shift and mask the bits to read/write out. Make sure to add a
check for system memory since pcc redefines the access_width to
subspace id.

If access_width is not set, then fall back to using bit_width.

[ rjw: Subject and changelog edits, comment adjustments ]</Note>
    </Notes>
    <CVE>CVE-2024-35995</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use WQ_MEM_RECLAIM flag for workqueue

Issue reported by customer during SRIOV testing, call trace:
When both i40e and the i40iw driver are loaded, a warning
in check_flush_dependency is being triggered. This seems
to be because of the i40e driver workqueue is allocated with
the WQ_MEM_RECLAIM flag, and the i40iw one is not.

Similar error was encountered on ice too and it was fixed by
removing the flag. Do the same for i40e too.

[Feb 9 09:08] ------------[ cut here ]------------
[  +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is
flushing !WQ_MEM_RECLAIM infiniband:0x0
[  +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966
check_flush_dependency+0x10b/0x120
[  +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq
snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4
nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr
rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma
intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif
isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal
intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core
iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore
ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich
intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad
xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe
drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel
libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror
dm_region_hash dm_log dm_mod fuse
[  +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not
tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1
[  +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS
SE5C620.86B.02.01.0013.121520200651 12/15/2020
[  +0.000001] Workqueue: i40e i40e_service_task [i40e]
[  +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120
[  +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48
81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd
ff &lt;0f&gt; 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90
[  +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282
[  +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:
0000000000000027
[  +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:
ffff94d47f620bc0
[  +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:
00000000ffff7fff
[  +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:
ffff94c5451ea180
[  +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:
ffff94c5f1330ab0
[  +0.000001] FS:  0000000000000000(0000) GS:ffff94d47f600000(0000)
knlGS:0000000000000000
[  +0.000002] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:
00000000007706f0
[  +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[  +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[  +0.000001] PKRU: 55555554
[  +0.000001] Call Trace:
[  +0.000001]  &lt;TASK&gt;
[  +0.000002]  ? __warn+0x80/0x130
[  +0.000003]  ? check_flush_dependency+0x10b/0x120
[  +0.000002]  ? report_bug+0x195/0x1a0
[  +0.000005]  ? handle_bug+0x3c/0x70
[  +0.000003]  ? exc_invalid_op+0x14/0x70
[  +0.000002]  ? asm_exc_invalid_op+0x16/0x20
[  +0.000006]  ? check_flush_dependency+0x10b/0x120
[  +0.000002]  ? check_flush_dependency+0x10b/0x120
[  +0.000002]  __flush_workqueue+0x126/0x3f0
[  +0.000015]  ib_cache_cleanup_one+0x1c/0xe0 [ib_core]
[  +0.000056]  __ib_unregister_device+0x6a/0xb0 [ib_core]
[  +0.000023]  ib_unregister_device_and_put+0x34/0x50 [ib_core]
[  +0.000020]  i40iw_close+0x4b/0x90 [irdma]
[  +0.000022]  i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e]
[  +0.000035]  i40e_service_task+0x126/0x190 [i40e]
[  +0.000024]  process_one_work+0x174/0x340
[  +0.000003]  worker_th
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-36004</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()

Extend a critical section to prevent chan from early freeing.
Also make the l2cap_connect() return type void. Nothing is using the
returned value but it is ugly to return a potentially freed pointer.
Making it void will help with backports because earlier kernels did use
the return value. Now the compile will break for kernels where this
patch is not a complete fix.

Call stack summary:

[use]
l2cap_bredr_sig_cmd
  l2cap_connect
    mutex_lock(&amp;conn-&gt;chan_lock);
  | chan = pchan-&gt;ops-&gt;new_connection(pchan); &lt;- alloc chan
  | __l2cap_chan_add(conn, chan);
  |   l2cap_chan_hold(chan);
  |   list_add(&amp;chan-&gt;list, &amp;conn-&gt;chan_l);   ... (1)
    mutex_unlock(&amp;conn-&gt;chan_lock);
    chan-&gt;conf_state              ... (4) &lt;- use after free

[free]
l2cap_conn_del
  mutex_lock(&amp;conn-&gt;chan_lock);
| foreach chan in conn-&gt;chan_l:            ... (2)
|   l2cap_chan_put(chan);
|     l2cap_chan_destroy
|       kfree(chan)               ... (3) &lt;- chan freed
  mutex_unlock(&amp;conn-&gt;chan_lock);

==================================================================
BUG: KASAN: slab-use-after-free in instrument_atomic_read
include/linux/instrumented.h:68 [inline]
BUG: KASAN: slab-use-after-free in _test_bit
include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0
net/bluetooth/l2cap_core.c:4260
Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311</Note>
    </Notes>
    <CVE>CVE-2024-36013</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: tproxy: bail out if IP has been disabled on the device

syzbot reports:
general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
[..]
RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62
Call Trace:
 nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline]
 nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168

__in_dev_get_rcu() can return NULL, so check for this.</Note>
    </Notes>
    <CVE>CVE-2024-36270</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_queue: acquire rcu_read_lock() in instance_destroy_rcu()

syzbot reported that nf_reinject() could be called without rcu_read_lock() :

WARNING: suspicious RCU usage
6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted

net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syz-executor.4/13427:
  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]
  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]
  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471
  #1: ffff88801ca92958 (&amp;inst-&gt;lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
  #1: ffff88801ca92958 (&amp;inst-&gt;lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]
  #1: ffff88801ca92958 (&amp;inst-&gt;lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172

stack backtrace:
CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Call Trace:
 &lt;IRQ&gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
  lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712
  nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]
  nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397
  nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]
  instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172
  rcu_do_batch kernel/rcu/tree.c:2196 [inline]
  rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471
  handle_softirqs+0x2d6/0x990 kernel/softirq.c:554
  __do_softirq kernel/softirq.c:588 [inline]
  invoke_softirq kernel/softirq.c:428 [inline]
  __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637
  irq_exit_rcu+0x9/0x30 kernel/softirq.c:649
  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]
  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043
 &lt;/IRQ&gt;
 &lt;TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-36286</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

SUNRPC: Fix loop termination condition in gss_free_in_token_pages()

The in_token-&gt;pages[] array is not NULL terminated. This results in
the following KASAN splat:

  KASAN: maybe wild-memory-access in range [0x04a2013400000008-0x04a201340000000f]</Note>
    </Notes>
    <CVE>CVE-2024-36288</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.</Note>
    </Notes>
    <CVE>CVE-2024-36592</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tipc: fix UAF in error path

Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported
a UAF in the tipc_buf_append() error path:

BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0
linux/net/core/skbuff.c:1183
Read of size 8 at addr ffff88804d2a7c80 by task poc/8034

CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.0-debian-1.16.0-5 04/01/2014
Call Trace:
 &lt;IRQ&gt;
 __dump_stack linux/lib/dump_stack.c:88
 dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106
 print_address_description linux/mm/kasan/report.c:377
 print_report+0xc4/0x620 linux/mm/kasan/report.c:488
 kasan_report+0xda/0x110 linux/mm/kasan/report.c:601
 kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183
 skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026
 skb_release_all linux/net/core/skbuff.c:1094
 __kfree_skb linux/net/core/skbuff.c:1108
 kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144
 kfree_skb linux/./include/linux/skbuff.h:1244
 tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186
 tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324
 tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824
 tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159
 tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390
 udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108
 udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186
 udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346
 __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422
 ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205
 ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233
 NF_HOOK linux/./include/linux/netfilter.h:314
 NF_HOOK linux/./include/linux/netfilter.h:308
 ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254
 dst_input linux/./include/net/dst.h:461
 ip_rcv_finish linux/net/ipv4/ip_input.c:449
 NF_HOOK linux/./include/linux/netfilter.h:314
 NF_HOOK linux/./include/linux/netfilter.h:308
 ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569
 __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534
 __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648
 process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976
 __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576
 napi_poll linux/net/core/dev.c:6645
 net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781
 __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553
 do_softirq linux/kernel/softirq.c:454
 do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441
 &lt;/IRQ&gt;
 &lt;TASK&gt;
 __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381
 local_bh_enable linux/./include/linux/bottom_half.h:33
 rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851
 __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378
 dev_queue_xmit linux/./include/linux/netdevice.h:3169
 neigh_hh_output linux/./include/net/neighbour.h:526
 neigh_output linux/./include/net/neighbour.h:540
 ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235
 __ip_finish_output linux/net/ipv4/ip_output.c:313
 __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295
 ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323
 NF_HOOK_COND linux/./include/linux/netfilter.h:303
 ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433
 dst_output linux/./include/net/dst.h:451
 ip_local_out linux/net/ipv4/ip_output.c:129
 ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492
 udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963
 udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250
 inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850
 sock_sendmsg_nosec linux/net/socket.c:730
 __sock_sendmsg linux/net/socket.c:745
 __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191
 __do_sys_sendto linux/net/socket.c:2203
 __se_sys_sendto linux/net/socket.c:2199
 __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199
 do_syscall_x64 linux/arch/x86/entry/common.c:52
 do_syscall_
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-36886</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipv6: prevent NULL dereference in ip6_output()

According to syzbot, there is a chance that ip6_dst_idev()
returns NULL in ip6_output(). Most places in IPv6 stack
deal with a NULL idev just fine, but not here.

syzbot reported:

general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]
CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237
Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 &lt;42&gt; 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff
RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202
RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000
RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48
RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad
R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0
R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000
FS:  00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358
  sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248
  sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653
  sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783
  sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline]
  sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212
  sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]
  sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169
  sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73
  __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234
  sctp_connect net/sctp/socket.c:4819 [inline]
  sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834
  __sys_connect_file net/socket.c:2048 [inline]
  __sys_connect+0x2df/0x310 net/socket.c:2065
  __do_sys_connect net/socket.c:2075 [inline]
  __se_sys_connect net/socket.c:2072 [inline]
  __x64_sys_connect+0x7a/0x90 net/socket.c:2072
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2024-36901</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()

syzbot is able to trigger the following crash [1],
caused by unsafe ip6_dst_idev() use.

Indeed ip6_dst_idev() can return NULL, and must always be checked.

[1]

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline]
 RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267
Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 &lt;42&gt; 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c
RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700
RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760
RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd
R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000
R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00
FS:  00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317
  fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108
  ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline]
  ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649
  ip6_route_output include/net/ip6_route.h:93 [inline]
  ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120
  ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250
  sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326
  sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455
  sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662
  sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099
  __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197
  sctp_connect net/sctp/socket.c:4819 [inline]
  sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834
  __sys_connect_file net/socket.c:2048 [inline]
  __sys_connect+0x2df/0x310 net/socket.c:2065
  __do_sys_connect net/socket.c:2075 [inline]
  __se_sys_connect net/socket.c:2072 [inline]
  __x64_sys_connect+0x7a/0x90 net/socket.c:2072
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2024-36902</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets

TCP_SYN_RECV state is really special, it is only used by
cross-syn connections, mostly used by fuzzers.

In the following crash [1], syzbot managed to trigger a divide
by zero in tcp_rcv_space_adjust()

A socket makes the following state transitions,
without ever calling tcp_init_transfer(),
meaning tcp_init_buffer_space() is also not called.

         TCP_CLOSE
connect()
         TCP_SYN_SENT
         TCP_SYN_RECV
shutdown() -&gt; tcp_shutdown(sk, SEND_SHUTDOWN)
         TCP_FIN_WAIT1

To fix this issue, change tcp_shutdown() to not
perform a TCP_SYN_RECV -&gt; TCP_FIN_WAIT1 transition,
which makes no sense anyway.

When tcp_rcv_state_process() later changes socket state
from TCP_SYN_RECV to TCP_ESTABLISH, then look at
sk-&gt;sk_shutdown to finally enter TCP_FIN_WAIT1 state,
and send a FIN packet from a sane socket state.

This means tcp_send_fin() can now be called from BH
context, and must use GFP_ATOMIC allocations.

[1]
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
 RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767
Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 &lt;48&gt; f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48
RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246
RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7
R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30
R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da
FS:  00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0
Call Trace:
 &lt;TASK&gt;
  tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513
  tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578
  inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680
  sock_recvmsg_nosec net/socket.c:1046 [inline]
  sock_recvmsg+0x109/0x280 net/socket.c:1068
  ____sys_recvmsg+0x1db/0x470 net/socket.c:2803
  ___sys_recvmsg net/socket.c:2845 [inline]
  do_recvmmsg+0x474/0xae0 net/socket.c:2939
  __sys_recvmmsg net/socket.c:3018 [inline]
  __do_sys_recvmmsg net/socket.c:3041 [inline]
  __se_sys_recvmmsg net/socket.c:3034 [inline]
  __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7faeb6363db9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9
RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005
RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c
R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001</Note>
    </Notes>
    <CVE>CVE-2024-36905</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: bnx2fc: Remove spin_lock_bh while releasing resources after upload

The session resources are used by FW and driver when session is offloaded,
once session is uploaded these resources are not used. The lock is not
required as these fields won't be used any longer. The offload and upload
calls are sequential, hence lock is not required.

This will suppress following BUG_ON():

[  449.843143] ------------[ cut here ]------------
[  449.848302] kernel BUG at mm/vmalloc.c:2727!
[  449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[  449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1
Rebooting.
[  449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016
[  449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]
[  449.882910] RIP: 0010:vunmap+0x2e/0x30
[  449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 &lt;0f&gt; 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41
[  449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206
[  449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005
[  449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000
[  449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf
[  449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000
[  449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0
[  449.953701] FS:  0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000
[  449.962732] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0
[  449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  449.993028] Call Trace:
[  449.995756]  __iommu_dma_free+0x96/0x100
[  450.000139]  bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]
[  450.006171]  bnx2fc_upload_session+0xce/0x100 [bnx2fc]
[  450.011910]  bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]
[  450.018136]  fc_rport_work+0x103/0x5b0 [libfc]
[  450.023103]  process_one_work+0x1e8/0x3c0
[  450.027581]  worker_thread+0x50/0x3b0
[  450.031669]  ? rescuer_thread+0x370/0x370
[  450.036143]  kthread+0x149/0x170
[  450.039744]  ? set_kthread_struct+0x40/0x40
[  450.044411]  ret_from_fork+0x22/0x30
[  450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls
[  450.048497]  libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler
[  450.159753] ---[ end trace 712de2c57c64abc8 ]---</Note>
    </Notes>
    <CVE>CVE-2024-36919</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Release hbalock before calling lpfc_worker_wake_up()

lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the
hbalock.  Thus, lpfc_worker_wake_up() should not be called while holding the
hbalock to avoid potential deadlock.</Note>
    </Notes>
    <CVE>CVE-2024-36924</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfs: Handle error of rpc_proc_register() in nfs_net_init().

syzkaller reported a warning [0] triggered while destroying immature
netns.

rpc_proc_register() was called in init_nfs_fs(), but its error
has been ignored since at least the initial commit 1da177e4c3f4
("Linux-2.6.12-rc2").

Recently, commit d47151b79e32 ("nfs: expose /proc/net/sunrpc/nfs
in net namespaces") converted the procfs to per-netns and made
the problem more visible.

Even when rpc_proc_register() fails, nfs_net_init() could succeed,
and thus nfs_net_exit() will be called while destroying the netns.

Then, remove_proc_entry() will be called for non-existing proc
directory and trigger the warning below.

Let's handle the error of rpc_proc_register() properly in nfs_net_init().

[0]:
name 'nfs'
WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711
Modules linked in:
CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711
Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff &lt;0f&gt; 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb
RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c
RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc
R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8
FS:  00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 rpc_proc_unregister+0x64/0x70 net/sunrpc/stats.c:310
 nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438
 ops_exit_list+0x62/0xb0 net/core/net_namespace.c:170
 setup_net+0x46c/0x660 net/core/net_namespace.c:372
 copy_net_ns+0x244/0x590 net/core/net_namespace.c:505
 create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110
 unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228
 ksys_unshare+0x342/0x760 kernel/fork.c:3322
 __do_sys_unshare kernel/fork.c:3393 [inline]
 __se_sys_unshare kernel/fork.c:3391 [inline]
 __x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x46/0x4e
RIP: 0033:0x7f30d0febe5d
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48
RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600
RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-36939</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en"> urllib3 is a user-friendly HTTP client library for Python. When using urllib3's proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected. However, when sending HTTP requests *without* using urllib3's proxy support, it's possible to accidentally configure the `Proxy-Authorization` header even though it won't have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn't treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn't strip the header on cross-origin redirects. Because this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident. Users should use urllib3's proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still decided to strip the header by default in order to further protect users who aren't using the correct approach. We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited: 1. Setting the `Proxy-Authorization` header without using urllib3's built-in proxy support. 2. Not disabling HTTP redirects. 3. Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin. Users are advised to update to either version 1.26.19 or version 2.2.2. Users unable to upgrade may use the `Proxy-Authorization` header with urllib3's `ProxyManager`, disable HTTP redirects using `redirects=False` when sending requests, or not user the `Proxy-Authorization` header as mitigations.</Note>
    </Notes>
    <CVE>CVE-2024-37891</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-urllib3-1.25.10-3.40.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix uninit-value in nci_rx_work

syzbot reported the following uninit-value access issue [1]

nci_rx_work() parses received packet from ndev-&gt;rx_q. It should be
validated header size, payload size and total packet size before
processing the packet. If an invalid packet is detected, it should be
silently discarded.</Note>
    </Notes>
    <CVE>CVE-2024-38381</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: bridge: xmit: make sure we have at least eth header len bytes

syzbot triggered an uninit value[1] error in bridge device's xmit path
by sending a short (less than ETH_HLEN bytes) skb. To fix it check if
we can actually pull that amount instead of assuming.

Tested with dropwatch:
 drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)
 origin: software
 timestamp: Mon May 13 11:31:53 2024 778214037 nsec
 protocol: 0x88a8
 length: 2
 original length: 2
 drop reason: PKT_TOO_SMALL

[1]
BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
 __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
 netdev_start_xmit include/linux/netdevice.h:4917 [inline]
 xmit_one net/core/dev.c:3531 [inline]
 dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
 __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341
 dev_queue_xmit include/linux/netdevice.h:3091 [inline]
 __bpf_tx_skb net/core/filter.c:2136 [inline]
 __bpf_redirect_common net/core/filter.c:2180 [inline]
 __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187
 ____bpf_clone_redirect net/core/filter.c:2460 [inline]
 bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432
 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997
 __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238
 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]
 __bpf_prog_run include/linux/filter.h:657 [inline]
 bpf_prog_run include/linux/filter.h:664 [inline]
 bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425
 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058
 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269
 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678
 __do_sys_bpf kernel/bpf/syscall.c:5767 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:5765 [inline]
 __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765
 x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322
 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+0x77/0x7f</Note>
    </Notes>
    <CVE>CVE-2024-38538</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: openvswitch: fix overwriting ct original tuple for ICMPv6

OVS_PACKET_CMD_EXECUTE has 3 main attributes:
 - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.
 - OVS_PACKET_ATTR_PACKET - Binary packet content.
 - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.

OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure
with the metadata like conntrack state, input port, recirculation id,
etc.  Then the packet itself gets parsed to populate the rest of the
keys from the packet headers.

Whenever the packet parsing code starts parsing the ICMPv6 header, it
first zeroes out fields in the key corresponding to Neighbor Discovery
information even if it is not an ND packet.

It is an 'ipv6.nd' field.  However, the 'ipv6' is a union that shares
the space between 'nd' and 'ct_orig' that holds the original tuple
conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.

ND packets should not normally have conntrack state, so it's fine to
share the space, but normal ICMPv6 Echo packets or maybe other types of
ICMPv6 can have the state attached and it should not be overwritten.

The issue results in all but the last 4 bytes of the destination
address being wiped from the original conntrack tuple leading to
incorrect packet matching and potentially executing wrong actions
in case this packet recirculates within the datapath or goes back
to userspace.

ND fields should not be accessed in non-ND packets, so not clearing
them should be fine.  Executing memset() only for actual ND packets to
avoid the issue.

Initializing the whole thing before parsing is needed because ND packet
may not contain all the options.

The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't
affect packets entering OVS datapath from network interfaces, because
in this case CT metadata is populated from skb after the packet is
already parsed.</Note>
    </Notes>
    <CVE>CVE-2024-38558</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: bfa: Ensure the copied buf is NUL terminated

Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from
userspace to that buffer. Later, we use sscanf on this buffer but we don't
ensure that the string is terminated inside the buffer, this can lead to
OOB read when using sscanf. Fix this issue by using memdup_user_nul instead
of memdup_user.</Note>
    </Notes>
    <CVE>CVE-2024-38560</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg

A data-race condition has been identified in af_unix. In one data path,
the write function unix_release_sock() atomically writes to
sk-&gt;sk_shutdown using WRITE_ONCE. However, on the reader side,
unix_stream_sendmsg() does not read it atomically. Consequently, this
issue is causing the following KCSAN splat to occur:

	BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg

	write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
	unix_release_sock (net/unix/af_unix.c:640)
	unix_release (net/unix/af_unix.c:1050)
	sock_close (net/socket.c:659 net/socket.c:1421)
	__fput (fs/file_table.c:422)
	__fput_sync (fs/file_table.c:508)
	__se_sys_close (fs/open.c:1559 fs/open.c:1541)
	__x64_sys_close (fs/open.c:1541)
	x64_sys_call (arch/x86/entry/syscall_64.c:33)
	do_syscall_64 (arch/x86/entry/common.c:?)
	entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

	read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
	unix_stream_sendmsg (net/unix/af_unix.c:2273)
	__sock_sendmsg (net/socket.c:730 net/socket.c:745)
	____sys_sendmsg (net/socket.c:2584)
	__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
	__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
	x64_sys_call (arch/x86/entry/syscall_64.c:33)
	do_syscall_64 (arch/x86/entry/common.c:?)
	entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

	value changed: 0x01 -&gt; 0x03

The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").

Commit e1d09c2c2f57 ("af_unix: Fix data races around sk-&gt;sk_shutdown.")
addressed a comparable issue in the past regarding sk-&gt;sk_shutdown.
However, it overlooked resolving this particular data path.
This patch only offending unix_stream_sendmsg() function, since the
other reads seem to be protected by unix_state_lock() as discussed in</Note>
    </Notes>
    <CVE>CVE-2024-38596</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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: timer: Set lower bound of start tick time

Currently ALSA timer doesn't have the lower limit of the start tick
time, and it allows a very small size, e.g. 1 tick with 1ns resolution
for hrtimer.  Such a situation may lead to an unexpected RCU stall,
where  the callback repeatedly queuing the expire update, as reported
by fuzzer.

This patch introduces a sanity check of the timer start tick time, so
that the system returns an error when a too small start size is set.
As of this patch, the lower limit is hard-coded to 100us, which is
small enough but can still work somehow.</Note>
    </Notes>
    <CVE>CVE-2024-38618</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vfio/pci: fix potential memory leak in vfio_intx_enable()

If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.</Note>
    </Notes>
    <CVE>CVE-2024-38632</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING

Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with
small possibility, the root cause is exactly the same as commit
bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")

However, Dan reported another hang after that, and junxiao investigated
the problem and found out that this is caused by plugged bio can't issue
from raid5d().

Current implementation in raid5d() has a weird dependence:

1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
   MD_SB_CHANGE_PENDING;
2) raid5d() handles IO in a deadloop, until all IO are issued;
3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;

This behaviour is introduce before v2.6, and for consequence, if other
context hold 'reconfig_mutex', and md_check_recovery() can't update
super_block, then raid5d() will waste one cpu 100% by the deadloop, until
'reconfig_mutex' is released.

Refer to the implementation from raid1 and raid10, fix this problem by
skipping issue IO if MD_SB_CHANGE_PENDING is still set after
md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'
is released. Meanwhile, the hang problem will be fixed as well.</Note>
    </Notes>
    <CVE>CVE-2024-39476</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 out-of-bounds read in bond_option_arp_ip_targets_set()

In function bond_option_arp_ip_targets_set(), if newval-&gt;string is an
empty string, newval-&gt;string+1 will point to the byte after the
string, causing an out-of-bound read.

BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418
Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107
CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:364 [inline]
 print_report+0xc1/0x5e0 mm/kasan/report.c:475
 kasan_report+0xbe/0xf0 mm/kasan/report.c:588
 strlen+0x7d/0xa0 lib/string.c:418
 __fortify_strlen include/linux/fortify-string.h:210 [inline]
 in4_pton+0xa3/0x3f0 net/core/utils.c:130
 bond_option_arp_ip_targets_set+0xc2/0x910
drivers/net/bonding/bond_options.c:1201
 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767
 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792
 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817
 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156
 dev_attr_store+0x54/0x80 drivers/base/core.c:2366
 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136
 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334
 call_write_iter include/linux/fs.h:2020 [inline]
 new_sync_write fs/read_write.c:491 [inline]
 vfs_write+0x96a/0xd80 fs/read_write.c:584
 ksys_write+0x122/0x250 fs/read_write.c:637
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
---[ end trace ]---

Fix it by adding a check of string length before using it.</Note>
    </Notes>
    <CVE>CVE-2024-39487</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: asm-bug: Add .align 2 to the end of __BUG_ENTRY

When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes
to bug_table entries, and as a result the last entry in a bug table will
be ignored, potentially leading to an unexpected panic(). All prior
entries in the table will be handled correctly.

The arm64 ABI requires that struct fields of up to 8 bytes are
naturally-aligned, with padding added within a struct such that struct
are suitably aligned within arrays.

When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:

	struct bug_entry {
		signed int      bug_addr_disp;	// 4 bytes
		signed int      file_disp;	// 4 bytes
		unsigned short  line;		// 2 bytes
		unsigned short  flags;		// 2 bytes
	}

... with 12 bytes total, requiring 4-byte alignment.

When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:

	struct bug_entry {
		signed int      bug_addr_disp;	// 4 bytes
		unsigned short  flags;		// 2 bytes
		&lt; implicit padding &gt;		// 2 bytes
	}

... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing
padding, requiring 4-byte alginment.

When we create a bug_entry in assembly, we align the start of the entry
to 4 bytes, which implicitly handles padding for any prior entries.
However, we do not align the end of the entry, and so when
CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding
bytes.

For the main kernel image this is not a problem as find_bug() doesn't
depend on the trailing padding bytes when searching for entries:

	for (bug = __start___bug_table; bug &lt; __stop___bug_table; ++bug)
		if (bugaddr == bug_addr(bug))
			return bug;

However for modules, module_bug_finalize() depends on the trailing
bytes when calculating the number of entries:

	mod-&gt;num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);

... and as the last bug_entry lacks the necessary padding bytes, this entry
will not be counted, e.g. in the case of a single entry:

	sechdrs[i].sh_size == 6
	sizeof(struct bug_entry) == 8;

	sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;

Consequently module_find_bug() will miss the last bug_entry when it does:

	for (i = 0; i &lt; mod-&gt;num_bugs; ++i, ++bug)
		if (bugaddr == bug_addr(bug))
			goto out;

... which can lead to a kenrel panic due to an unhandled bug.

This can be demonstrated with the following module:

	static int __init buginit(void)
	{
		WARN(1, "hello\n");
		return 0;
	}

	static void __exit bugexit(void)
	{
	}

	module_init(buginit);
	module_exit(bugexit);
	MODULE_LICENSE("GPL");

... which will trigger a kernel panic when loaded:

	------------[ cut here ]------------
	hello
	Unexpected kernel BRK exception at EL1
	Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP
	Modules linked in: hello(O+)
	CPU: 0 PID: 50 Comm: insmod Tainted: G           O       6.9.1 #8
	Hardware name: linux,dummy-virt (DT)
	pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
	pc : buginit+0x18/0x1000 [hello]
	lr : buginit+0x18/0x1000 [hello]
	sp : ffff800080533ae0
	x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000
	x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58
	x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0
	x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006
	x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720
	x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312
	x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8
	x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000
	x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000
	x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0
	Call trace:
	 buginit+0x18/0x1000 [hello]
	 do_one_initcall+0x80/0x1c8
	 do_init_module+0x60/0x218
	 load_module+0x1ba4/0x1d70
	 __do_sys_init_module+0x198/0x1d0
	 __arm64_sys_init_module+0x1c/0x28
	 invoke_syscall+0x48/0x114
	 el0_svc
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-39488</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipv6: sr: fix memleak in seg6_hmac_init_algo

seg6_hmac_init_algo returns without cleaning up the previous allocations
if one fails, so it's going to leak all that memory and the crypto tfms.

Update seg6_hmac_exit to only free the memory when allocated, so we can
reuse the code directly.</Note>
    </Notes>
    <CVE>CVE-2024-39489</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

ipv6: sr: fix missing sk_buff release in seg6_input_core

The seg6_input() function is responsible for adding the SRH into a
packet, delegating the operation to the seg6_input_core(). This function
uses the skb_cow_head() to ensure that there is sufficient headroom in
the sk_buff for accommodating the link-layer header.
In the event that the skb_cow_header() function fails, the
seg6_input_core() catches the error but it does not release the sk_buff,
which will result in a memory leak.

This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG due
to headroom too small after SRH push") and persists even after commit
7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"),
where the entire seg6_input() code was refactored to deal with netfilter
hooks.

The proposed patch addresses the identified memory leak by requiring the
seg6_input_core() function to release the sk_buff in the event that
skb_cow_head() fails.</Note>
    </Notes>
    <CVE>CVE-2024-39490</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

ima: Fix use-after-free on a dentry's dname.name

-&gt;d_name.name can change on rename and the earlier value can be freed;
there are conditions sufficient to stabilize it (-&gt;d_lock on dentry,
-&gt;d_lock on its parent, -&gt;i_rwsem exclusive on the parent's inode,
rename_lock), but none of those are met at any of the sites. Take a stable
snapshot of the name instead.</Note>
    </Notes>
    <CVE>CVE-2024-39494</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

vmci: prevent speculation leaks by sanitizing event in event_deliver()

Coverity spotted that event_msg is controlled by user-space,
event_msg-&gt;event_data.event is passed to event_deliver() and used
as an index without sanitization.

This change ensures that the event index is sanitized to mitigate any
possibility of speculative information leaks.

This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.

Only compile tested, no access to HW.</Note>
    </Notes>
    <CVE>CVE-2024-39499</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-39501</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet

In lio_vf_rep_copy_packet() pg_info-&gt;page is compared to a NULL value,
but then it is unconditionally passed to skb_add_rx_frag() which looks
strange and could lead to null pointer dereference.

lio_vf_rep_copy_packet() call trace looks like:
	octeon_droq_process_packets
	 octeon_droq_fast_process_packets
	  octeon_droq_dispatch_pkt
	   octeon_create_recv_info
	    ...search in the dispatch_list...
	     -&gt;disp_fn(rdisp-&gt;rinfo, ...)
	      lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)
In this path there is no code which sets pg_info-&gt;page to NULL.
So this check looks unneeded and doesn't solve potential problem.
But I guess the author had reason to add a check and I have no such card
and can't do real test.
In addition, the code in the function liquidio_push_packet() in
liquidio/lio_core.c does exactly the same.

Based on this, I consider the most acceptable compromise solution to
adjust this issue by moving skb_add_rx_frag() into conditional scope.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-39506</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 problem in concurrent scenario

When link status change, the nic driver need to notify the roce
driver to handle this event, but at this time, the roce driver
may uninit, then cause kernel crash.

To fix the problem, when link status change, need to check
whether the roce registered, and when uninit, need to wait link
update finish.</Note>
    </Notes>
    <CVE>CVE-2024-39507</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

HID: core: remove unnecessary WARN_ON() in implement()

Syzkaller hit a warning [1] in a call to implement() when trying
to write a value into a field of smaller size in an output report.

Since implement() already has a warn message printed out with the
help of hid_warn() and value in question gets trimmed with:
	...
	value &amp;= m;
	...
WARN_ON may be considered superfluous. Remove it to suppress future
syzkaller triggers.

[1]
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
Modules linked in:
CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]
RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
...
Call Trace:
 &lt;TASK&gt;
 __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]
 usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636
 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:904 [inline]
 __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
...</Note>
    </Notes>
    <CVE>CVE-2024-39509</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The "ipaddress" module contained incorrect information about whether certain IPv4 and IPv6 addresses were designated as "globally reachable" or "private". This affected the is_private and is_global properties of the ipaddress.IPv4Address, ipaddress.IPv4Network, ipaddress.IPv6Address, and ipaddress.IPv6Network classes, where values wouldn't be returned in accordance with the latest information from the IANA Special-Purpose Address Registries.

CPython 3.12.4 and 3.13.0a6 contain updated information from these registries and thus have the intended behavior.</Note>
    </Notes>
    <CVE>CVE-2024-4032</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libpython3_4m1_0-3.4.10-25.145.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-3.4.10-25.145.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-base-3.4.10-25.145.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:

scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory

There is a potential out-of-bounds access when using test_bit() on a single
word. The test_bit() and set_bit() functions operate on long values, and
when testing or setting a single word, they can exceed the word
boundary. KASAN detects this issue and produces a dump:

	 BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas

	 Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965

For full log, please look at [1].

Make the allocation at least the size of sizeof(unsigned long) so that
set_bit() and test_bit() have sufficient room for read/write operations
without overwriting unallocated memory.

[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/</Note>
    </Notes>
    <CVE>CVE-2024-40901</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: class: cdc-wdm: Fix CPU lockup caused by excessive log messages

The syzbot fuzzer found that the interrupt-URB completion callback in
the cdc-wdm driver was taking too long, and the driver's immediate
resubmission of interrupt URBs with -EPROTO status combined with the
dummy-hcd emulation to cause a CPU lockup:

cdc_wdm 1-1:1.0: nonzero urb status received: -71
cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes
watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]
CPU#0 Utilization every 4s during lockup:
	#1:  98% system,	  0% softirq,	  3% hardirq,	  0% idle
	#2:  98% system,	  0% softirq,	  3% hardirq,	  0% idle
	#3:  98% system,	  0% softirq,	  3% hardirq,	  0% idle
	#4:  98% system,	  0% softirq,	  3% hardirq,	  0% idle
	#5:  98% system,	  1% softirq,	  3% hardirq,	  0% idle
Modules linked in:
irq event stamp: 73096
hardirqs last  enabled at (73095): [&lt;ffff80008037bc00&gt;] console_emit_next_record kernel/printk/printk.c:2935 [inline]
hardirqs last  enabled at (73095): [&lt;ffff80008037bc00&gt;] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994
hardirqs last disabled at (73096): [&lt;ffff80008af10b00&gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
hardirqs last disabled at (73096): [&lt;ffff80008af10b00&gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
softirqs last  enabled at (73048): [&lt;ffff8000801ea530&gt;] softirq_handle_end kernel/softirq.c:400 [inline]
softirqs last  enabled at (73048): [&lt;ffff8000801ea530&gt;] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582
softirqs last disabled at (73043): [&lt;ffff800080020de8&gt;] __do_softirq+0x14/0x20 kernel/softirq.c:588
CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G        W          6.10.0-rc2-syzkaller-g8867bbd4a056 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024

Testing showed that the problem did not occur if the two error
messages -- the first two lines above -- were removed; apparently adding
material to the kernel log takes a surprisingly large amount of time.

In any case, the best approach for preventing these lockups and to
avoid spamming the log with thousands of error messages per second is
to ratelimit the two dev_err() calls.  Therefore we replace them with
dev_err_ratelimited().</Note>
    </Notes>
    <CVE>CVE-2024-40904</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 deadlock in ieee80211_sta_ps_deliver_wakeup()

The ieee80211_sta_ps_deliver_wakeup() function takes sta-&gt;ps_lock to
synchronizes with ieee80211_tx_h_unicast_ps_buf() which is called from
softirq context. However using only spin_lock() to get sta-&gt;ps_lock in
ieee80211_sta_ps_deliver_wakeup() does not prevent softirq to execute
on this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try to
take this same lock ending in deadlock. Below is an example of rcu stall
that arises in such situation.

 rcu: INFO: rcu_sched self-detected stall on CPU
 rcu:    2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996
 rcu:    (t=42586894 jiffies g=2057 q=362405 ncpus=4)
 CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G        W          6.4.0-02158-g1b062f552873 #742
 Hardware name: RPT (r1) (DT)
 pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : queued_spin_lock_slowpath+0x58/0x2d0
 lr : invoke_tx_handlers_early+0x5b4/0x5c0
 sp : ffff00001ef64660
 x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8
 x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000
 x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000
 x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000
 x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80
 x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da
 x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440
 x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880
 x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000
 x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8
 Call trace:
  queued_spin_lock_slowpath+0x58/0x2d0
  ieee80211_tx+0x80/0x12c
  ieee80211_tx_pending+0x110/0x278
  tasklet_action_common.constprop.0+0x10c/0x144
  tasklet_action+0x20/0x28
  _stext+0x11c/0x284
  ____do_softirq+0xc/0x14
  call_on_irq_stack+0x24/0x34
  do_softirq_own_stack+0x18/0x20
  do_softirq+0x74/0x7c
  __local_bh_enable_ip+0xa0/0xa4
  _ieee80211_wake_txqs+0x3b0/0x4b8
  __ieee80211_wake_queue+0x12c/0x168
  ieee80211_add_pending_skbs+0xec/0x138
  ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480
  ieee80211_mps_sta_status_update.part.0+0xd8/0x11c
  ieee80211_mps_sta_status_update+0x18/0x24
  sta_apply_parameters+0x3bc/0x4c0
  ieee80211_change_station+0x1b8/0x2dc
  nl80211_set_station+0x444/0x49c
  genl_family_rcv_msg_doit.isra.0+0xa4/0xfc
  genl_rcv_msg+0x1b0/0x244
  netlink_rcv_skb+0x38/0x10c
  genl_rcv+0x34/0x48
  netlink_unicast+0x254/0x2bc
  netlink_sendmsg+0x190/0x3b4
  ____sys_sendmsg+0x1e8/0x218
  ___sys_sendmsg+0x68/0x8c
  __sys_sendmsg+0x44/0x84
  __arm64_sys_sendmsg+0x20/0x28
  do_el0_svc+0x6c/0xe8
  el0_svc+0x14/0x48
  el0t_64_sync_handler+0xb0/0xb4
  el0t_64_sync+0x14c/0x150

Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raise
on the same CPU that is holding the lock.</Note>
    </Notes>
    <CVE>CVE-2024-40912</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vmxnet3: disable rx data ring on dma allocation failure

When vmxnet3_rq_create() fails to allocate memory for rq-&gt;data_ring.base,
the subsequent call to vmxnet3_rq_destroy_all_rxdataring does not reset
rq-&gt;data_ring.desc_size for the data ring that failed, which presumably
causes the hypervisor to reference it on packet reception.

To fix this bug, rq-&gt;data_ring.desc_size needs to be set to 0 to tell
the hypervisor to disable this feature.

[   95.436876] kernel BUG at net/core/skbuff.c:207!
[   95.439074] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[   95.440411] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 6.9.3-dirty #1
[   95.441558] Hardware name: VMware, Inc. VMware Virtual
Platform/440BX Desktop Reference Platform, BIOS 6.00 12/12/2018
[   95.443481] RIP: 0010:skb_panic+0x4d/0x4f
[   95.444404] Code: 4f 70 50 8b 87 c0 00 00 00 50 8b 87 bc 00 00 00 50
ff b7 d0 00 00 00 4c 8b 8f c8 00 00 00 48 c7 c7 68 e8 be 9f e8 63 58 f9
ff &lt;0f&gt; 0b 48 8b 14 24 48 c7 c1 d0 73 65 9f e8 a1 ff ff ff 48 8b 14 24
[   95.447684] RSP: 0018:ffffa13340274dd0 EFLAGS: 00010246
[   95.448762] RAX: 0000000000000089 RBX: ffff8fbbc72b02d0 RCX: 000000000000083f
[   95.450148] RDX: 0000000000000000 RSI: 00000000000000f6 RDI: 000000000000083f
[   95.451520] RBP: 000000000000002d R08: 0000000000000000 R09: ffffa13340274c60
[   95.452886] R10: ffffffffa04ed468 R11: 0000000000000002 R12: 0000000000000000
[   95.454293] R13: ffff8fbbdab3c2d0 R14: ffff8fbbdbd829e0 R15: ffff8fbbdbd809e0
[   95.455682] FS:  0000000000000000(0000) GS:ffff8fbeefd80000(0000) knlGS:0000000000000000
[   95.457178] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   95.458340] CR2: 00007fd0d1f650c8 CR3: 0000000115f28000 CR4: 00000000000406f0
[   95.459791] Call Trace:
[   95.460515]  &lt;IRQ&gt;
[   95.461180]  ? __die_body.cold+0x19/0x27
[   95.462150]  ? die+0x2e/0x50
[   95.462976]  ? do_trap+0xca/0x110
[   95.463973]  ? do_error_trap+0x6a/0x90
[   95.464966]  ? skb_panic+0x4d/0x4f
[   95.465901]  ? exc_invalid_op+0x50/0x70
[   95.466849]  ? skb_panic+0x4d/0x4f
[   95.467718]  ? asm_exc_invalid_op+0x1a/0x20
[   95.468758]  ? skb_panic+0x4d/0x4f
[   95.469655]  skb_put.cold+0x10/0x10
[   95.470573]  vmxnet3_rq_rx_complete+0x862/0x11e0 [vmxnet3]
[   95.471853]  vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3]
[   95.473185]  __napi_poll+0x2b/0x160
[   95.474145]  net_rx_action+0x2c6/0x3b0
[   95.475115]  handle_softirqs+0xe7/0x2a0
[   95.476122]  __irq_exit_rcu+0x97/0xb0
[   95.477109]  common_interrupt+0x85/0xa0
[   95.478102]  &lt;/IRQ&gt;
[   95.478846]  &lt;TASK&gt;
[   95.479603]  asm_common_interrupt+0x26/0x40
[   95.480657] RIP: 0010:pv_native_safe_halt+0xf/0x20
[   95.481801] Code: 22 d7 e9 54 87 01 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d 93 ba 3b 00 fb f4 &lt;e9&gt; 2c 87 01 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90
[   95.485563] RSP: 0018:ffffa133400ffe58 EFLAGS: 00000246
[   95.486882] RAX: 0000000000004000 RBX: ffff8fbbc1d14064 RCX: 0000000000000000
[   95.488477] RDX: ffff8fbeefd80000 RSI: ffff8fbbc1d14000 RDI: 0000000000000001
[   95.490067] RBP: ffff8fbbc1d14064 R08: ffffffffa0652260 R09: 00000000000010d3
[   95.491683] R10: 0000000000000018 R11: ffff8fbeefdb4764 R12: ffffffffa0652260
[   95.493389] R13: ffffffffa06522e0 R14: 0000000000000001 R15: 0000000000000000
[   95.495035]  acpi_safe_halt+0x14/0x20
[   95.496127]  acpi_idle_do_entry+0x2f/0x50
[   95.497221]  acpi_idle_enter+0x7f/0xd0
[   95.498272]  cpuidle_enter_state+0x81/0x420
[   95.499375]  cpuidle_enter+0x2d/0x40
[   95.500400]  do_idle+0x1e5/0x240
[   95.501385]  cpu_startup_entry+0x29/0x30
[   95.502422]  start_secondary+0x11c/0x140
[   95.503454]  common_startup_64+0x13e/0x141
[   95.504466]  &lt;/TASK&gt;
[   95.505197] Modules linked in: 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_ip
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-40923</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: check n_ssids before accessing the ssids

In some versions of cfg80211, the ssids poinet might be a valid one even
though n_ssids is 0. Accessing the pointer in this case will cuase an
out-of-bound access. Fix this by checking n_ssids first.</Note>
    </Notes>
    <CVE>CVE-2024-40929</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/exynos/vidi: fix memory leak in .get_modes()

The duplicated EDID is never freed. Fix it.</Note>
    </Notes>
    <CVE>CVE-2024-40932</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gve: Clear napi-&gt;skb before dev_kfree_skb_any()

gve_rx_free_skb incorrectly leaves napi-&gt;skb referencing an skb after it
is freed with dev_kfree_skb_any(). This can result in a subsequent call
to napi_get_frags returning a dangling pointer.

Fix this by clearing napi-&gt;skb before the skb is freed.</Note>
    </Notes>
    <CVE>CVE-2024-40937</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: don't read past the mfuart notifcation

In case the firmware sends a notification that claims it has more data
than it has, we will read past that was allocated for the notification.
Remove the print of the buffer, we won't see it by default. If needed,
we can see the content with tracing.

This was reported by KFENCE.</Note>
    </Notes>
    <CVE>CVE-2024-40941</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mesh: Fix leak of mesh_preq_queue objects

The hwmp code use objects of type mesh_preq_queue, added to a list in
ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath
gets deleted, ex mesh interface is removed, the entries in that list will
never get cleaned. Fix this by flushing all corresponding items of the
preq_queue in mesh_path_flush_pending().

This should take care of KASAN reports like this:

unreferenced object 0xffff00000668d800 (size 128):
  comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s)
  hex dump (first 32 bytes):
    00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff  ..........h.....
    8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00  ....&gt;...........
  backtrace:
    [&lt;000000007302a0b6&gt;] __kmem_cache_alloc_node+0x1e0/0x35c
    [&lt;00000000049bd418&gt;] kmalloc_trace+0x34/0x80
    [&lt;0000000000d792bb&gt;] mesh_queue_preq+0x44/0x2a8
    [&lt;00000000c99c3696&gt;] mesh_nexthop_resolve+0x198/0x19c
    [&lt;00000000926bf598&gt;] ieee80211_xmit+0x1d0/0x1f4
    [&lt;00000000fc8c2284&gt;] __ieee80211_subif_start_xmit+0x30c/0x764
    [&lt;000000005926ee38&gt;] ieee80211_subif_start_xmit+0x9c/0x7a4
    [&lt;000000004c86e916&gt;] dev_hard_start_xmit+0x174/0x440
    [&lt;0000000023495647&gt;] __dev_queue_xmit+0xe24/0x111c
    [&lt;00000000cfe9ca78&gt;] batadv_send_skb_packet+0x180/0x1e4
    [&lt;000000007bacc5d5&gt;] batadv_v_elp_periodic_work+0x2f4/0x508
    [&lt;00000000adc3cd94&gt;] process_one_work+0x4b8/0xa1c
    [&lt;00000000b36425d1&gt;] worker_thread+0x9c/0x634
    [&lt;0000000005852dd5&gt;] kthread+0x1bc/0x1c4
    [&lt;000000005fccd770&gt;] ret_from_fork+0x10/0x20
unreferenced object 0xffff000009051f00 (size 128):
  comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s)
  hex dump (first 32 bytes):
    90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff  ..........h.....
    36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff  6'.......Xy.....
  backtrace:
    [&lt;000000007302a0b6&gt;] __kmem_cache_alloc_node+0x1e0/0x35c
    [&lt;00000000049bd418&gt;] kmalloc_trace+0x34/0x80
    [&lt;0000000000d792bb&gt;] mesh_queue_preq+0x44/0x2a8
    [&lt;00000000c99c3696&gt;] mesh_nexthop_resolve+0x198/0x19c
    [&lt;00000000926bf598&gt;] ieee80211_xmit+0x1d0/0x1f4
    [&lt;00000000fc8c2284&gt;] __ieee80211_subif_start_xmit+0x30c/0x764
    [&lt;000000005926ee38&gt;] ieee80211_subif_start_xmit+0x9c/0x7a4
    [&lt;000000004c86e916&gt;] dev_hard_start_xmit+0x174/0x440
    [&lt;0000000023495647&gt;] __dev_queue_xmit+0xe24/0x111c
    [&lt;00000000cfe9ca78&gt;] batadv_send_skb_packet+0x180/0x1e4
    [&lt;000000007bacc5d5&gt;] batadv_v_elp_periodic_work+0x2f4/0x508
    [&lt;00000000adc3cd94&gt;] process_one_work+0x4b8/0xa1c
    [&lt;00000000b36425d1&gt;] worker_thread+0x9c/0x634
    [&lt;0000000005852dd5&gt;] kthread+0x1bc/0x1c4
    [&lt;000000005fccd770&gt;] ret_from_fork+0x10/0x20</Note>
    </Notes>
    <CVE>CVE-2024-40942</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix races between hole punching and AIO+DIO

After commit "ocfs2: return real error code in ocfs2_dio_wr_get_block",
fstests/generic/300 become from always failed to sometimes failed:

========================================================================
[  473.293420 ] run fstests generic/300

[  475.296983 ] JBD2: Ignoring recovery information on journal
[  475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode.
[  494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found
[  494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.
[  494.292018 ] OCFS2: File system is now read-only.
[  494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30
[  494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3
fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072
=========================================================================

In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten
extents to a list.  extents are also inserted into extent tree in
ocfs2_write_begin_nolock.  Then another thread call fallocate to puch a
hole at one of the unwritten extent.  The extent at cpos was removed by
ocfs2_remove_extent().  At end io worker thread, ocfs2_search_extent_list
found there is no such extent at the cpos.

    T1                        T2                T3
                              inode lock
                                ...
                                insert extents
                                ...
                              inode unlock
ocfs2_fallocate
 __ocfs2_change_file_space
  inode lock
  lock ip_alloc_sem
  ocfs2_remove_inode_range inode
   ocfs2_remove_btree_range
    ocfs2_remove_extent
    ^---remove the extent at cpos 78723
  ...
  unlock ip_alloc_sem
  inode unlock
                                       ocfs2_dio_end_io
                                        ocfs2_dio_end_io_write
                                         lock ip_alloc_sem
                                         ocfs2_mark_extent_written
                                          ocfs2_change_extent_flag
                                           ocfs2_search_extent_list
                                           ^---failed to find extent
                                          ...
                                          unlock ip_alloc_sem

In most filesystems, fallocate is not compatible with racing with AIO+DIO,
so fix it by adding to wait for all dio before fallocate/punch_hole like
ext4.</Note>
    </Notes>
    <CVE>CVE-2024-40943</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()

Use {READ,WRITE}_ONCE() to access kvm-&gt;last_boosted_vcpu to ensure the
loads and stores are atomic.  In the extremely unlikely scenario the
compiler tears the stores, it's theoretically possible for KVM to attempt
to get a vCPU using an out-of-bounds index, e.g. if the write is split
into multiple 8-bit stores, and is paired with a 32-bit load on a VM with
257 vCPUs:

  CPU0                              CPU1
  last_boosted_vcpu = 0xff;

                                    (last_boosted_vcpu = 0x100)
                                    last_boosted_vcpu[15:8] = 0x01;
  i = (last_boosted_vcpu = 0x1ff)
                                    last_boosted_vcpu[7:0] = 0x00;

  vcpu = kvm-&gt;vcpu_array[0x1ff];

As detected by KCSAN:

  BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]

  write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:
  kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm
  handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
  vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
		 arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
  vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
  kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
  kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
  __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
  __x64_sys_ioctl (fs/ioctl.c:890)
  x64_sys_call (arch/x86/entry/syscall_64.c:33)
  do_syscall_64 (arch/x86/entry/common.c:?)
  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

  read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4:
  kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm
  handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
  vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
			arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
  vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
  kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
  kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
  __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
  __x64_sys_ioctl (fs/ioctl.c:890)
  x64_sys_call (arch/x86/entry/syscall_64.c:33)
  do_syscall_64 (arch/x86/entry/common.c:?)
  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

  value changed: 0x00000012 -&gt; 0x00000000</Note>
    </Notes>
    <CVE>CVE-2024-40953</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()

ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.

syzbot reported:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker
 RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64
Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00
RSP: 0018:ffffc90000117378 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7
RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98
RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000
R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline]
  xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline]
  xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541
  xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835
  xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline]
  xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201
  xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline]
  xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309
  ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256
  send6+0x611/0xd20 drivers/net/wireguard/socket.c:139
  wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178
  wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200
  wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40
  wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51
  process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
  process_scheduled_works kernel/workqueue.c:3312 [inline]
  worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393
  kthread+0x2c1/0x3a0 kernel/kthread.c:389
  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244</Note>
    </Notes>
    <CVE>CVE-2024-40959</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: lpi2c: Avoid calling clk_get_rate during transfer

Instead of repeatedly calling clk_get_rate for each transfer, lock
the clock rate and cache the value.
A deadlock has been observed while adding tlv320aic32x4 audio codec to
the system. When this clock provider adds its clock, the clk mutex is
locked already, it needs to access i2c, which in return needs the mutex
for clk_get_rate as well.</Note>
    </Notes>
    <CVE>CVE-2024-40965</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: add the option to have a tty reject a new ldisc

... and use it to limit the virtual terminals to just N_TTY.  They are
kind of special, and in particular, the "con_write()" routine violates
the "writes cannot sleep" rule that some ldiscs rely on.

This avoids the

   BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659

when N_GSM has been attached to a virtual console, and gsmld_write()
calls con_write() while holding a spinlock, and con_write() then tries
to get the console lock.</Note>
    </Notes>
    <CVE>CVE-2024-40966</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: imx: Introduce timeout when waiting on transmitter empty

By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential
deadlock.

In case of the timeout, there is not much we can do, so we simply ignore
the transmitter state and optimistically try to continue.</Note>
    </Notes>
    <CVE>CVE-2024-40967</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: qedi: Fix crash while reading debugfs attribute

The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly
on a __user pointer, which results into the crash.

To fix this issue, use a small local stack buffer for sprintf() and then
call simple_read_from_buffer(), which in turns make the copy_to_user()
call.

BUG: unable to handle page fault for address: 00007f4801111000
PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0
Oops: 0002 [#1] PREEMPT SMP PTI
Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023
RIP: 0010:memcpy_orig+0xcd/0x130
RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202
RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f
RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000
RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572
R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff
R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af
FS:  00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? __die_body+0x1a/0x60
 ? page_fault_oops+0x183/0x510
 ? exc_page_fault+0x69/0x150
 ? asm_exc_page_fault+0x22/0x30
 ? memcpy_orig+0xcd/0x130
 vsnprintf+0x102/0x4c0
 sprintf+0x51/0x80
 qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]
 full_proxy_read+0x50/0x80
 vfs_read+0xa5/0x2e0
 ? folio_add_new_anon_rmap+0x44/0xa0
 ? set_pte_at+0x15/0x30
 ? do_pte_missing+0x426/0x7f0
 ksys_read+0xa5/0xe0
 do_syscall_64+0x58/0x80
 ? __count_memcg_events+0x46/0x90
 ? count_memcg_event_mm+0x3d/0x60
 ? handle_mm_fault+0x196/0x2f0
 ? do_user_addr_fault+0x267/0x890
 ? exc_page_fault+0x69/0x150
 entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7f4800f20b4d</Note>
    </Notes>
    <CVE>CVE-2024-40978</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-40982</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."

Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid
"Info: mapping multiple BARs. Your kernel is fine.""). The initial
purpose of this commit was to stop memory mappings for operation
regions from overlapping page boundaries, as it can trigger warnings
if different page attributes are present.

However, it was found that when this situation arises, mapping
continues until the boundary's end, but there is still an attempt to
read/write the entire length of the map, leading to a NULL pointer
deference. For example, if a four-byte mapping request is made but
only one byte is mapped because it hits the current page boundary's
end, a four-byte read/write attempt is still made, resulting in a NULL
pointer deference.

Instead, map the entire length, as the ACPI specification does not
mandate that it must be within the same page boundary. It is
permissible for it to be mapped across different regions.</Note>
    </Notes>
    <CVE>CVE-2024-40984</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 UBSAN warning in kv_dpm.c

Adds bounds check for sumo_vid_mapping_entry.</Note>
    </Notes>
    <CVE>CVE-2024-40987</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/radeon: fix UBSAN warning in kv_dpm.c

Adds bounds check for sumo_vid_mapping_entry.</Note>
    </Notes>
    <CVE>CVE-2024-40988</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/mlx5: Add check for srq max_sge attribute

max_sge attribute is passed by the user, and is inserted and used
unchecked, so verify that the value doesn't exceed maximum allowed value
before using it.</Note>
    </Notes>
    <CVE>CVE-2024-40990</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: act_api: fix possible infinite loop in tcf_idr_check_alloc()

syzbot found hanging tasks waiting on rtnl_lock [1]

A reproducer is available in the syzbot bug.

When a request to add multiple actions with the same index is sent, the
second request will block forever on the first request. This holds
rtnl_lock, and causes tasks to hang.

Return -EAGAIN to prevent infinite looping, while keeping documented
behavior.

[1]

INFO: task kworker/1:0:5088 blocked for more than 143 seconds.
Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0
"echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000
Workqueue: events_power_efficient reg_check_chans_work
Call Trace:
&lt;TASK&gt;
context_switch kernel/sched/core.c:5409 [inline]
__schedule+0xf15/0x5d00 kernel/sched/core.c:6746
__schedule_loop kernel/sched/core.c:6823 [inline]
schedule+0xe7/0x350 kernel/sched/core.c:6838
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895
__mutex_lock_common kernel/locking/mutex.c:684 [inline]
__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752
wiphy_lock include/net/cfg80211.h:5953 [inline]
reg_leave_invalid_chans net/wireless/reg.c:2466 [inline]
reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481</Note>
    </Notes>
    <CVE>CVE-2024-40995</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 uninitialized ratelimit_state-&gt;lock access in __ext4_fill_super()

In the following concurrency we will access the uninitialized rs-&gt;lock:

ext4_fill_super
  ext4_register_sysfs
   // sysfs registered msg_ratelimit_interval_ms
                             // Other processes modify rs-&gt;interval to
                             // non-zero via msg_ratelimit_interval_ms
  ext4_orphan_cleanup
    ext4_msg(sb, KERN_INFO, "Errors on filesystem, "
      __ext4_msg
        ___ratelimit(&amp;(EXT4_SB(sb)-&gt;s_msg_ratelimit_state)
          if (!rs-&gt;interval)  // do nothing if interval is 0
            return 1;
          raw_spin_trylock_irqsave(&amp;rs-&gt;lock, flags)
            raw_spin_trylock(lock)
              _raw_spin_trylock
                __raw_spin_trylock
                  spin_acquire(&amp;lock-&gt;dep_map, 0, 1, _RET_IP_)
                    lock_acquire
                      __lock_acquire
                        register_lock_class
                          assign_lock_key
                            dump_stack();
  ratelimit_state_init(&amp;sbi-&gt;s_msg_ratelimit_state, 5 * HZ, 10);
    raw_spin_lock_init(&amp;rs-&gt;lock);
    // init rs-&gt;lock here

and get the following dump_stack:

=========================================================
INFO: trying to register non-static key.
The code is fine but needs lockdep annotation, or maybe
you didn't initialize this object before use?
turning off the locking correctness validator.
CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504
[...]
Call Trace:
 dump_stack_lvl+0xc5/0x170
 dump_stack+0x18/0x30
 register_lock_class+0x740/0x7c0
 __lock_acquire+0x69/0x13a0
 lock_acquire+0x120/0x450
 _raw_spin_trylock+0x98/0xd0
 ___ratelimit+0xf6/0x220
 __ext4_msg+0x7f/0x160 [ext4]
 ext4_orphan_cleanup+0x665/0x740 [ext4]
 __ext4_fill_super+0x21ea/0x2b10 [ext4]
 ext4_fill_super+0x14d/0x360 [ext4]
[...]
=========================================================

Normally interval is 0 until s_msg_ratelimit_state is initialized, so
___ratelimit() does nothing. But registering sysfs precedes initializing
rs-&gt;lock, so it is possible to change rs-&gt;interval to a non-zero value
via the msg_ratelimit_interval_ms interface of sysfs while rs-&gt;lock is
uninitialized, and then a call to ext4_msg triggers the problem by
accessing an uninitialized rs-&gt;lock. Therefore register sysfs after all
initializations are complete to avoid such problems.</Note>
    </Notes>
    <CVE>CVE-2024-40998</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ena: Add validation for completion descriptors consistency

Validate that `first` flag is set only for the first
descriptor in multi-buffer packets.
In case of an invalid descriptor, a reset will occur.
A new reset reason for RX data corruption has been added.</Note>
    </Notes>
    <CVE>CVE-2024-40999</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

filelock: Remove locks reliably when fcntl/close race is detected

When fcntl_setlk() races with close(), it removes the created lock with
do_lock_file_wait().
However, LSMs can allow the first do_lock_file_wait() that created the lock
while denying the second do_lock_file_wait() that tries to remove the lock.
Separately, posix_lock_file() could also fail to
remove a lock due to GFP_KERNEL allocation failure (when splitting a range
in the middle).

After the bug has been triggered, use-after-free reads will occur in
lock_get_status() when userspace reads /proc/locks. This can likely be used
to read arbitrary kernel memory, but can't corrupt kernel memory.

Fix it by calling locks_remove_posix() instead, which is designed to
reliably get rid of POSIX locks associated with the given file and
files_struct and is also used by filp_flush().</Note>
    </Notes>
    <CVE>CVE-2024-41012</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xfs: add bounds checking to xlog_recover_process_data

There is a lack of verification of the space occupied by fixed members
of xlog_op_header in the xlog_recover_process_data.

We can create a crafted image to trigger an out of bounds read by
following these steps:
    1) Mount an image of xfs, and do some file operations to leave records
    2) Before umounting, copy the image for subsequent steps to simulate
       abnormal exit. Because umount will ensure that tail_blk and
       head_blk are the same, which will result in the inability to enter
       xlog_recover_process_data
    3) Write a tool to parse and modify the copied image in step 2
    4) Make the end of the xlog_op_header entries only 1 byte away from
       xlog_rec_header-&gt;h_size
    5) xlog_rec_header-&gt;h_num_logops++
    6) Modify xlog_rec_header-&gt;h_crc

Fix:
Add a check to make sure there is sufficient space to access fixed members
of xlog_op_header.</Note>
    </Notes>
    <CVE>CVE-2024-41014</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: add bounds checking to ocfs2_check_dir_entry()

This adds sanity checks for ocfs2_dir_entry to make sure all members of
ocfs2_dir_entry don't stray beyond valid memory region.</Note>
    </Notes>
    <CVE>CVE-2024-41015</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()

xattr in ocfs2 maybe 'non-indexed', which saved with additional space
requested.  It's better to check if the memory is out of bound before
memcmp, although this possibility mainly comes from crafted poisonous
images.</Note>
    </Notes>
    <CVE>CVE-2024-41016</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

filelock: Fix fcntl/close race recovery compat path

When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when
fcntl/close race is detected"), I missed that there are two copies of the
code I was patching: The normal version, and the version for 64-bit offsets
on 32-bit kernels.
Thanks to Greg KH for stumbling over this while doing the stable
backport...

Apply exactly the same fix to the compat path for 32-bit kernels.</Note>
    </Notes>
    <CVE>CVE-2024-41020</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor

Syzbot has identified a bug in usbcore (see the Closes: tag below)
caused by our assumption that the reserved bits in an endpoint
descriptor's bEndpointAddress field will always be 0.  As a result of
the bug, the endpoint_is_duplicate() routine in config.c (and possibly
other routines as well) may believe that two descriptors are for
distinct endpoints, even though they have the same direction and
endpoint number.  This can lead to confusion, including the bug
identified by syzbot (two descriptors with matching endpoint numbers
and directions, where one was interrupt and the other was bulk).

To fix the bug, we will clear the reserved bits in bEndpointAddress
when we parse the descriptor.  (Note that both the USB-2.0 and USB-3.1
specs say these bits are "Reserved, reset to zero".)  This requires us
to make a copy of the descriptor earlier in usb_parse_endpoint() and
use the copy instead of the original when checking for duplicates.</Note>
    </Notes>
    <CVE>CVE-2024-41035</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: reject claimed-as-LCP but actually malformed packets

Since 'ppp_async_encode()' assumes valid LCP packets (with code
from 1 to 7 inclusive), add 'ppp_check_packet()' to ensure that
LCP packet has an actual body beyond PPP_LCP header bytes, and
reject claimed-as-LCP but actually malformed data otherwise.</Note>
    </Notes>
    <CVE>CVE-2024-41044</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

skmsg: Skip zero length skb in sk_msg_recvmsg

When running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch
platform, the following kernel panic occurs:

  [...]
  Oops[#1]:
  CPU: 22 PID: 2824 Comm: test_progs Tainted: G           OE  6.10.0-rc2+ #18
  Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018
     ... ...
     ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560
    ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0
   CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
   PRMD: 0000000c (PPLV0 +PIE +PWE)
   EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
   ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
  ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
   BADV: 0000000000000040
   PRID: 0014c011 (Loongson-64bit, Loongson-3C5000)
  Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack
  Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...)
  Stack : ...
  Call Trace:
  [&lt;9000000004162774&gt;] copy_page_to_iter+0x74/0x1c0
  [&lt;90000000048bf6c0&gt;] sk_msg_recvmsg+0x120/0x560
  [&lt;90000000049f2b90&gt;] tcp_bpf_recvmsg_parser+0x170/0x4e0
  [&lt;90000000049aae34&gt;] inet_recvmsg+0x54/0x100
  [&lt;900000000481ad5c&gt;] sock_recvmsg+0x7c/0xe0
  [&lt;900000000481e1a8&gt;] __sys_recvfrom+0x108/0x1c0
  [&lt;900000000481e27c&gt;] sys_recvfrom+0x1c/0x40
  [&lt;9000000004c076ec&gt;] do_syscall+0x8c/0xc0
  [&lt;9000000003731da4&gt;] handle_syscall+0xc4/0x160
  Code: ...
  ---[ end trace 0000000000000000 ]---
  Kernel panic - not syncing: Fatal exception
  Kernel relocated by 0x3510000
   .text @ 0x9000000003710000
   .data @ 0x9000000004d70000
   .bss  @ 0x9000000006469400
  ---[ end Kernel panic - not syncing: Fatal exception ]---
  [...]

This crash happens every time when running sockmap_skb_verdict_shutdown
subtest in sockmap_basic.

This crash is because a NULL pointer is passed to page_address() in the
sk_msg_recvmsg(). Due to the different implementations depending on the
architecture, page_address(NULL) will trigger a panic on Loongarch
platform but not on x86 platform. So this bug was hidden on x86 platform
for a while, but now it is exposed on Loongarch platform. The root cause
is that a zero length skb (skb-&gt;len == 0) was put on the queue.

This zero length skb is a TCP FIN packet, which was sent by shutdown(),
invoked in test_sockmap_skb_verdict_shutdown():

	shutdown(p1, SHUT_WR);

In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no
page is put to this sge (see sg_set_page in sg_set_page), but this empty
sge is queued into ingress_msg list.

And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by
sg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes it
to kmap_local_page() and to page_address(), then kernel panics.

To solve this, we should skip this zero length skb. So in sk_msg_recvmsg(),
if copy is zero, that means it's a zero length skb, skip invoking
copy_page_to_iter(). We are using the EFAULT return triggered by
copy_page_to_iter to check for is_fin in tcp_bpf.c.</Note>
    </Notes>
    <CVE>CVE-2024-41048</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hfsplus: fix uninit-value in copy_name

[syzbot reported]
BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160
 sized_strscpy+0xc4/0x160
 copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411
 hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750
 vfs_listxattr fs/xattr.c:493 [inline]
 listxattr+0x1f3/0x6b0 fs/xattr.c:840
 path_listxattr fs/xattr.c:864 [inline]
 __do_sys_listxattr fs/xattr.c:876 [inline]
 __se_sys_listxattr fs/xattr.c:873 [inline]
 __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873
 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195
 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+0x77/0x7f

Uninit was created at:
 slab_post_alloc_hook mm/slub.c:3877 [inline]
 slab_alloc_node mm/slub.c:3918 [inline]
 kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065
 kmalloc include/linux/slab.h:628 [inline]
 hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699
 vfs_listxattr fs/xattr.c:493 [inline]
 listxattr+0x1f3/0x6b0 fs/xattr.c:840
 path_listxattr fs/xattr.c:864 [inline]
 __do_sys_listxattr fs/xattr.c:876 [inline]
 __se_sys_listxattr fs/xattr.c:873 [inline]
 __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873
 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195
 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+0x77/0x7f
[Fix]
When allocating memory to strbuf, initialize memory to 0.</Note>
    </Notes>
    <CVE>CVE-2024-41059</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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/radeon: check bo_va-&gt;bo is non-NULL before using it

The call to radeon_vm_clear_freed might clear bo_va-&gt;bo, so
we have to check it before dereferencing it.</Note>
    </Notes>
    <CVE>CVE-2024-41060</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bluetooth/l2cap: sync sock recv cb and release

The problem occurs between the system call to close the sock and hci_rx_work,
where the former releases the sock and the latter accesses it without lock protection.

           CPU0                       CPU1
           ----                       ----
           sock_close                 hci_rx_work
	   l2cap_sock_release         hci_acldata_packet
	   l2cap_sock_kill            l2cap_recv_frame
	   sk_free                    l2cap_conless_channel
	                              l2cap_sock_recv_cb

If hci_rx_work processes the data that needs to be received before the sock is
closed, then everything is normal; Otherwise, the work thread may access the
released sock when receiving data.

Add a chan mutex in the rx callback of the sock to achieve synchronization between
the sock release and recv cb.

Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.</Note>
    </Notes>
    <CVE>CVE-2024-41062</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_core: cancel all works upon hci_unregister_dev()

syzbot is reporting that calling hci_release_dev() from hci_error_reset()
due to hci_dev_put() from hci_error_reset() can cause deadlock at
destroy_workqueue(), for hci_error_reset() is called from
hdev-&gt;req_workqueue which destroy_workqueue() needs to flush.

We need to make sure that hdev-&gt;{rx_work,cmd_work,tx_work} which are
queued into hdev-&gt;workqueue and hdev-&gt;{power_on,error_reset} which are
queued into hdev-&gt;req_workqueue are no longer running by the moment

       destroy_workqueue(hdev-&gt;workqueue);
       destroy_workqueue(hdev-&gt;req_workqueue);

are called from hci_release_dev().

Call cancel_work_sync() on these work items from hci_unregister_dev()
as soon as hdev-&gt;list is removed from hci_dev_list.</Note>
    </Notes>
    <CVE>CVE-2024-41063</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

powerpc/eeh: avoid possible crash when edev-&gt;pdev changes

If a PCI device is removed during eeh_pe_report_edev(), edev-&gt;pdev
will change and can cause a crash, hold the PCI rescan/remove lock
while taking a copy of edev-&gt;pdev-&gt;bus.</Note>
    </Notes>
    <CVE>CVE-2024-41064</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ibmvnic: Add tx check to prevent skb leak

Below is a summary of how the driver stores a reference to an skb during
transmit:
    tx_buff[free_map[consumer_index]]-&gt;skb = new_skb;
    free_map[consumer_index] = IBMVNIC_INVALID_MAP;
    consumer_index ++;
Where variable data looks like this:
    free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3]
                                               	consumer_index^
    tx_buff == [skb=null, skb=&lt;ptr&gt;, skb=&lt;ptr&gt;, skb=null, skb=null]

The driver has checks to ensure that free_map[consumer_index] pointed to
a valid index but there was no check to ensure that this index pointed
to an unused/null skb address. So, if, by some chance, our free_map and
tx_buff lists become out of sync then we were previously risking an
skb memory leak. This could then cause tcp congestion control to stop
sending packets, eventually leading to ETIMEDOUT.

Therefore, add a conditional to ensure that the skb address is null. If
not then warn the user (because this is still a bug that should be
patched) and free the old pointer to prevent memleak/tcp problems.</Note>
    </Notes>
    <CVE>CVE-2024-41066</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/sclp: Fix sclp_init() cleanup on failure

If sclp_init() fails it only partially cleans up: if there are multiple
failing calls to sclp_init() sclp_state_change_event will be added several
times to sclp_reg_list, which results in the following warning:

------------[ cut here ]------------
list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10.
WARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3
Krnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8)
           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
...
Call Trace:
 [&lt;000003ffe0d6076a&gt;] __list_add_valid_or_report+0xe2/0xf8
([&lt;000003ffe0d60766&gt;] __list_add_valid_or_report+0xde/0xf8)
 [&lt;000003ffe0a8d37e&gt;] sclp_init+0x40e/0x450
 [&lt;000003ffe00009f2&gt;] do_one_initcall+0x42/0x1e0
 [&lt;000003ffe15b77a6&gt;] do_initcalls+0x126/0x150
 [&lt;000003ffe15b7a0a&gt;] kernel_init_freeable+0x1ba/0x1f8
 [&lt;000003ffe0d6650e&gt;] kernel_init+0x2e/0x180
 [&lt;000003ffe000301c&gt;] __ret_from_fork+0x3c/0x60
 [&lt;000003ffe0d759ca&gt;] ret_from_fork+0xa/0x30

Fix this by removing sclp_state_change_event from sclp_reg_list when
sclp_init() fails.</Note>
    </Notes>
    <CVE>CVE-2024-41068</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()

Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().

It looks up `stt` from tablefd, but then continues to use it after doing
fdput() on the returned fd. After the fdput() the tablefd is free to be
closed by another thread. The close calls kvm_spapr_tce_release() and
then release_spapr_tce_table() (via call_rcu()) which frees `stt`.

Although there are calls to rcu_read_lock() in
kvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent
the UAF, because `stt` is used outside the locked regions.

With an artifcial delay after the fdput() and a userspace program which
triggers the race, KASAN detects the UAF:

  BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
  Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505
  CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1
  Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV
  Call Trace:
    dump_stack_lvl+0xb4/0x108 (unreliable)
    print_report+0x2b4/0x6ec
    kasan_report+0x118/0x2b0
    __asan_load4+0xb8/0xd0
    kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
    kvm_vfio_set_attr+0x524/0xac0 [kvm]
    kvm_device_ioctl+0x144/0x240 [kvm]
    sys_ioctl+0x62c/0x1810
    system_call_exception+0x190/0x440
    system_call_vectored_common+0x15c/0x2ec
  ...
  Freed by task 0:
   ...
   kfree+0xec/0x3e0
   release_spapr_tce_table+0xd4/0x11c [kvm]
   rcu_core+0x568/0x16a0
   handle_softirqs+0x23c/0x920
   do_softirq_own_stack+0x6c/0x90
   do_softirq_own_stack+0x58/0x90
   __irq_exit_rcu+0x218/0x2d0
   irq_exit+0x30/0x80
   arch_local_irq_restore+0x128/0x230
   arch_local_irq_enable+0x1c/0x30
   cpuidle_enter_state+0x134/0x5cc
   cpuidle_enter+0x6c/0xb0
   call_cpuidle+0x7c/0x100
   do_idle+0x394/0x410
   cpu_startup_entry+0x60/0x70
   start_secondary+0x3fc/0x410
   start_secondary_prolog+0x10/0x14

Fix it by delaying the fdput() until `stt` is no longer in use, which
is effectively the entire function. To keep the patch minimal add a call
to fdput() at each of the existing return paths. Future work can convert
the function to goto or __cleanup style cleanup.

With the fix in place the test case no longer triggers the UAF.</Note>
    </Notes>
    <CVE>CVE-2024-41070</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-41071</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: wext: add extra SIOCSIWSCAN data check

In 'cfg80211_wext_siwscan()', add extra check whether number of
channels passed via 'ioctl(sock, SIOCSIWSCAN, ...)' doesn't exceed
IW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise.</Note>
    </Notes>
    <CVE>CVE-2024-41072</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: avoid double free special payload

If a discard request needs to be retried, and that retry may fail before
a new special payload is added, a double free will result. Clear the
RQF_SPECIAL_LOAD when the request is cleaned.</Note>
    </Notes>
    <CVE>CVE-2024-41073</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: qgroup: fix quota root leak after quota disable failure

If during the quota disable we fail when cleaning the quota tree or when
deleting the root from the root tree, we jump to the 'out' label without
ever dropping the reference on the quota root, resulting in a leak of the
root since fs_info-&gt;quota_root is no longer pointing to the root (we have
set it to NULL just before those steps).

Fix this by always doing a btrfs_put_root() call under the 'out' label.
This is a problem that exists since qgroups were first added in 2012 by
commit bed92eae26cc ("Btrfs: qgroup implementation and prototypes"), but
back then we missed a kfree on the quota root and free_extent_buffer()
calls on its root and commit root nodes, since back then roots were not
yet reference counted.</Note>
    </Notes>
    <CVE>CVE-2024-41078</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

nvmet: always initialize cqe.result

The spec doesn't mandate that the first two double words (aka results)
for the command queue entry need to be set to 0 when they are not
used (not specified). Though, the target implemention returns 0 for TCP
and FC but not for RDMA.

Let's make RDMA behave the same and thus explicitly initializing the
result field. This prevents leaking any data from the stack.</Note>
    </Notes>
    <CVE>CVE-2024-41079</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ila: block BH in ila_output()

As explained in commit 1378817486d6 ("tipc: block BH
before using dst_cache"), net/core/dst_cache.c
helpers need to be called with BH disabled.

ila_output() is called from lwtunnel_output()
possibly from process context, and under rcu_read_lock().

We might be interrupted by a softirq, re-enter ila_output()
and corrupt dst_cache data structures.

Fix the race by using local_bh_disable().</Note>
    </Notes>
    <CVE>CVE-2024-41081</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-fabrics: use reserved tag for reg read/write command

In some scenarios, if too many commands are issued by nvme command in
the same time by user tasks, this may exhaust all tags of admin_q. If
a reset (nvme reset or IO timeout) occurs before these commands finish,
reconnect routine may fail to update nvme regs due to insufficient tags,
which will cause kernel hang forever. In order to workaround this issue,
maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved
tags. This maybe safe for nvmf:

1. For the disable ctrl path,  we will not issue connect command
2. For the enable ctrl / fw activate path, since connect and reg_xx()
   are called serially.

So the reserved tags may still be enough while reg_xx() use reserved tags.</Note>
    </Notes>
    <CVE>CVE-2024-41082</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ata: libata-core: Fix double free on error

If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump
to the err_out label, which will call devres_release_group().
devres_release_group() will trigger a call to ata_host_release().
ata_host_release() calls kfree(host), so executing the kfree(host) in
ata_host_alloc() will lead to a double free:

kernel BUG at mm/slub.c:553!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:kfree+0x2cf/0x2f0
Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da
RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246
RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320
RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0
RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000
R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780
R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006
FS:  00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? __die_body.cold+0x19/0x27
 ? die+0x2e/0x50
 ? do_trap+0xca/0x110
 ? do_error_trap+0x6a/0x90
 ? kfree+0x2cf/0x2f0
 ? exc_invalid_op+0x50/0x70
 ? kfree+0x2cf/0x2f0
 ? asm_exc_invalid_op+0x1a/0x20
 ? ata_host_alloc+0xf5/0x120 [libata]
 ? ata_host_alloc+0xf5/0x120 [libata]
 ? kfree+0x2cf/0x2f0
 ata_host_alloc+0xf5/0x120 [libata]
 ata_host_alloc_pinfo+0x14/0xa0 [libata]
 ahci_init_one+0x6c9/0xd20 [ahci]

Ensure that we will not call kfree(host) twice, by performing the kfree()
only if the devres_open_group() call failed.</Note>
    </Notes>
    <CVE>CVE-2024-41087</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes

In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is
assigned to mode, which will lead to a possible NULL pointer dereference
on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().
Add a check to avoid null pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2024-41089</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tap: add missing verification for short frame

The cited commit missed to check against the validity of the frame length
in the tap_get_user_xdp() path, which could cause a corrupted skb to be
sent downstack. Even before the skb is transmitted, the
tap_get_user_xdp()--&gt;skb_set_network_header() may assume the size is more
than ETH_HLEN. Once transmitted, this could either cause out-of-bound
access beyond the actual length, or confuse the underlayer with incorrect
or inconsistent header length in the skb metadata.

In the alternative path, tap_get_user() already prohibits short frame which
has the length less than Ethernet header size from being transmitted.

This is to drop any frame shorter than the Ethernet header size just like
how tap_get_user() does.

CVE: CVE-2024-41090</Note>
    </Notes>
    <CVE>CVE-2024-41090</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

tun: add missing verification for short frame

The cited commit missed to check against the validity of the frame length
in the tun_xdp_one() path, which could cause a corrupted skb to be sent
downstack. Even before the skb is transmitted, the
tun_xdp_one--&gt;eth_type_trans() may access the Ethernet header although it
can be less than ETH_HLEN. Once transmitted, this could either cause
out-of-bound access beyond the actual length, or confuse the underlayer
with incorrect or inconsistent header length in the skb metadata.

In the alternative path, tun_get_user() already prohibits short frame which
has the length less than Ethernet header size from being transmitted for
IFF_TAP.

This is to drop any frame shorter than the Ethernet header size just like
how tun_get_user() does.

CVE: CVE-2024-41091</Note>
    </Notes>
    <CVE>CVE-2024-41091</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes

In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is
assigned to mode, which will lead to a possible NULL pointer dereference
on failure of drm_mode_duplicate(). Add a check to avoid npd.</Note>
    </Notes>
    <CVE>CVE-2024-41095</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: atm: cxacru: fix endpoint checking in cxacru_bind()

Syzbot is still reporting quite an old issue [1] that occurs due to
incomplete checking of present usb endpoints. As such, wrong
endpoints types may be used at urb sumbitting stage which in turn
triggers a warning in usb_submit_urb().

Fix the issue by verifying that required endpoint types are present
for both in and out endpoints, taking into account cmd endpoint type.

Unfortunately, this patch has not been tested on real hardware.

[1] Syzbot report:
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
Modules linked in:
CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
...
Call Trace:
 cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649
 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760
 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209
 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055
 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363
 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396
 call_driver_probe drivers/base/dd.c:517 [inline]
 really_probe+0x23c/0xcd0 drivers/base/dd.c:595
 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747
 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777
 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894
 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427
 __device_attach+0x228/0x4a0 drivers/base/dd.c:965
 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487
 device_add+0xc2f/0x2180 drivers/base/core.c:3354
 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170
 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238
 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293</Note>
    </Notes>
    <CVE>CVE-2024-41097</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ata: libata-core: Fix null pointer dereference on error

If the ata_port_alloc() call in ata_host_alloc() fails,
ata_host_release() will get called.

However, the code in ata_host_release() tries to free ata_port struct
members unconditionally, which can lead to the following:

BUG: unable to handle page fault for address: 0000000000003990
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata]
Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41
RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246
RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0
RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68
R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004
R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006
FS:  00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? __die_body.cold+0x19/0x27
 ? page_fault_oops+0x15a/0x2f0
 ? exc_page_fault+0x7e/0x180
 ? asm_exc_page_fault+0x26/0x30
 ? ata_host_release.cold+0x2f/0x6e [libata]
 ? ata_host_release.cold+0x2f/0x6e [libata]
 release_nodes+0x35/0xb0
 devres_release_group+0x113/0x140
 ata_host_alloc+0xed/0x120 [libata]
 ata_host_alloc_pinfo+0x14/0xa0 [libata]
 ahci_init_one+0x6c9/0xd20 [ahci]

Do not access ata_port struct members unconditionally.</Note>
    </Notes>
    <CVE>CVE-2024-41098</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Moby is an open-source project created by Docker for software containerization. A security vulnerability has been detected in certain versions of Docker Engine, which could allow an attacker to bypass authorization plugins (AuthZ) under specific circumstances. The base likelihood of this being exploited is low.

Using a specially-crafted API request, an Engine API client could make the daemon forward the request or response to an authorization plugin without the body. In certain circumstances, the authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it.

A security issue was discovered In 2018, where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. Although this issue was fixed in Docker Engine v18.09.1 in January 2019, the fix was not carried forward to later major versions, resulting in a regression. Anyone who depends on authorization plugins that introspect the request and/or response body to make access control decisions is potentially impacted.

Docker EE v19.03.x and all versions of Mirantis Container Runtime are not vulnerable.

docker-ce v27.1.1 containes patches to fix the vulnerability. Patches have also been merged into the master, 19.03, 20.0, 23.0, 24.0, 25.0, 26.0, and 26.1 release branches. If one is unable to upgrade immediately, avoid using AuthZ plugins and/or restrict access to the Docker API to trusted parties, following the principle of least privilege.</Note>
    </Notes>
    <CVE>CVE-2024-41110</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:docker-26.1.5_ce-98.120.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>critical</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers

register store validation for NFT_DATA_VALUE is conditional, however,
the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This
only requires a new helper function to infer the register type from the
set datatype so this conditional check can be removed. Otherwise,
pointer to chain object can be leaked through the registers.</Note>
    </Notes>
    <CVE>CVE-2024-42070</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

ocfs2: fix DIO failure due to insufficient transaction credits

The code in ocfs2_dio_end_io_write() estimates number of necessary
transaction credits using ocfs2_calc_extend_credits().  This however does
not take into account that the IO could be arbitrarily large and can
contain arbitrary number of extents.

Extent tree manipulations do often extend the current transaction but not
in all of the cases.  For example if we have only single block extents in
the tree, ocfs2_mark_extent_written() will end up calling
ocfs2_replace_extent_rec() all the time and we will never extend the
current transaction and eventually exhaust all the transaction credits if
the IO contains many single block extents.  Once that happens a
WARN_ON(jbd2_handle_buffer_credits(handle) &lt;= 0) is triggered in
jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to
this error.  This was actually triggered by one of our customers on a
heavily fragmented OCFS2 filesystem.

To fix the issue make sure the transaction always has enough credits for
one extent insert before each call of ocfs2_mark_extent_written().

Heming Zhao said:

------
PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error"

PID: xxx  TASK: xxxx  CPU: 5  COMMAND: "SubmitThread-CA"
  #0 machine_kexec at ffffffff8c069932
  #1 __crash_kexec at ffffffff8c1338fa
  #2 panic at ffffffff8c1d69b9
  #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2]
  #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2]
  #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2]
  #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2]
  #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2]
  #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2]
  #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]
#10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]
#11 dio_complete at ffffffff8c2b9fa7
#12 do_blockdev_direct_IO at ffffffff8c2bc09f
#13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]
#14 generic_file_direct_write at ffffffff8c1dcf14
#15 __generic_file_write_iter at ffffffff8c1dd07b
#16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]
#17 aio_write at ffffffff8c2cc72e
#18 kmem_cache_alloc at ffffffff8c248dde
#19 do_io_submit at ffffffff8c2ccada
#20 do_syscall_64 at ffffffff8c004984
#21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba</Note>
    </Notes>
    <CVE>CVE-2024-42077</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xdp: Remove WARN() from __xdp_reg_mem_model()

syzkaller reports a warning in __xdp_reg_mem_model().

The warning occurs only if __mem_id_init_hash_table() returns an error. It
returns the error in two cases:

  1. memory allocation fails;
  2. rhashtable_init() fails when some fields of rhashtable_params
     struct are not initialized properly.

The second case cannot happen since there is a static const rhashtable_params
struct with valid fields. So, warning is only triggered when there is a
problem with memory allocation.

Thus, there is no sense in using WARN() to handle this error and it can be
safely removed.

WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299

CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299

Call Trace:
 xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344
 xdp_test_run_setup net/bpf/test_run.c:188 [inline]
 bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377
 bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267
 bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240
 __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649
 __do_sys_bpf kernel/bpf/syscall.c:5738 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:5736 [inline]
 __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736
 do_syscall_64+0xfb/0x240
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

Found by Linux Verification Center (linuxtesting.org) with syzkaller.</Note>
    </Notes>
    <CVE>CVE-2024-42082</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER

In create_pinctrl(), pinctrl_maps_mutex is acquired before calling
add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()
calls pinctrl_free(). However, pinctrl_free() attempts to acquire
pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to
a potential deadlock.

This patch resolves the issue by releasing pinctrl_maps_mutex before
calling pinctrl_free(), preventing the deadlock.

This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.</Note>
    </Notes>
    <CVE>CVE-2024-42090</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Avoid explicit cpumask var allocation on stack

For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
variable on stack is not recommended since it can cause potential stack
overflow.

Instead, kernel code should always use *cpumask_var API(s) to allocate
cpumask var in config-neutral way, leaving allocation strategy to
CONFIG_CPUMASK_OFFSTACK.

Use *cpumask_var API(s) to address it.</Note>
    </Notes>
    <CVE>CVE-2024-42093</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: stop playing stack games in profile_pc()

The 'profile_pc()' function is used for timer-based profiling, which
isn't really all that relevant any more to begin with, but it also ends
up making assumptions based on the stack layout that aren't necessarily
valid.

Basically, the code tries to account the time spent in spinlocks to the
caller rather than the spinlock, and while I support that as a concept,
it's not worth the code complexity or the KASAN warnings when no serious
profiling is done using timers anyway these days.

And the code really does depend on stack layout that is only true in the
simplest of cases.  We've lost the comment at some point (I think when
the 32-bit and 64-bit code was unified), but it used to say:

	Assume the lock function has either no stack frame or a copy
	of eflags from PUSHF.

which explains why it just blindly loads a word or two straight off the
stack pointer and then takes a minimal look at the values to just check
if they might be eflags or the return pc:

	Eflags always has bits 22 and up cleared unlike kernel addresses

but that basic stack layout assumption assumes that there isn't any lock
debugging etc going on that would complicate the code and cause a stack
frame.

It causes KASAN unhappiness reported for years by syzkaller [1] and
others [2].

With no real practical reason for this any more, just remove the code.

Just for historical interest, here's some background commits relating to
this code from 2006:

  0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels")
  31679f38d886 ("Simplify profile_pc on x86-64")

and a code unification from 2009:

  ef4512882dbe ("x86: time_32/64.c unify profile_pc")

but the basics of this thing actually goes back to before the git tree.</Note>
    </Notes>
    <CVE>CVE-2024-42096</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ecdh - explicitly zeroize private_key

private_key is overwritten with the key parameter passed in by the
caller (if present), or alternatively a newly generated private key.
However, it is possible that the caller provides a key (or the newly
generated key) which is shorter than the previous key. In that
scenario, some key material from the previous key would not be
overwritten. The easiest solution is to explicitly zeroize the entire
private_key array first.

Note that this patch slightly changes the behavior of this function:
previously, if the ecc_gen_privkey failed, the old private_key would
remain. Now, the private_key is always zeroized. This behavior is
consistent with the case where params.key is set and ecc_is_key_valid
fails.</Note>
    </Notes>
    <CVE>CVE-2024-42098</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/nouveau: fix null pointer dereference in nouveau_connector_get_modes

In nouveau_connector_get_modes(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a possible NULL pointer
dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.</Note>
    </Notes>
    <CVE>CVE-2024-42101</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

inet_diag: Initialize pad field in struct inet_diag_req_v2

KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw
sockets uses the pad field in struct inet_diag_req_v2 for the
underlying protocol. This field corresponds to the sdiag_raw_protocol
field in struct inet_diag_req_raw.

inet_diag_get_exact_compat() converts inet_diag_req to
inet_diag_req_v2, but leaves the pad field uninitialized. So the issue
occurs when raw_lookup() accesses the sdiag_raw_protocol field.

Fix this by initializing the pad field in
inet_diag_get_exact_compat(). Also, do the same fix in
inet_diag_dump_compat() to avoid the similar issue in the future.

[1]
BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]
BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71
 raw_lookup net/ipv4/raw_diag.c:49 [inline]
 raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71
 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99
 inet_diag_cmd_exact+0x7d9/0x980
 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]
 inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426
 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564
 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297
 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
 netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361
 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0x332/0x3d0 net/socket.c:745
 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585
 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639
 __sys_sendmsg net/socket.c:2668 [inline]
 __do_sys_sendmsg net/socket.c:2677 [inline]
 __se_sys_sendmsg net/socket.c:2675 [inline]
 __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675
 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was stored to memory at:
 raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71
 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99
 inet_diag_cmd_exact+0x7d9/0x980
 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]
 inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426
 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564
 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297
 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
 netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361
 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0x332/0x3d0 net/socket.c:745
 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585
 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639
 __sys_sendmsg net/socket.c:2668 [inline]
 __do_sys_sendmsg net/socket.c:2677 [inline]
 __se_sys_sendmsg net/socket.c:2675 [inline]
 __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675
 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Local variable req.i created at:
 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline]
 inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426
 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282

CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014</Note>
    </Notes>
    <CVE>CVE-2024-42106</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from __netif_rx()

The following is emitted when using idxd (DSA) dmanegine as the data
mover for ntb_transport that ntb_netdev uses.

[74412.546922] BUG: using smp_processor_id() in preemptible [00000000] code: irq/52-idxd-por/14526
[74412.556784] caller is netif_rx_internal+0x42/0x130
[74412.562282] CPU: 6 PID: 14526 Comm: irq/52-idxd-por Not tainted 6.9.5 #5
[74412.569870] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 02/08/2024
[74412.581699] Call Trace:
[74412.584514]  &lt;TASK&gt;
[74412.586933]  dump_stack_lvl+0x55/0x70
[74412.591129]  check_preemption_disabled+0xc8/0xf0
[74412.596374]  netif_rx_internal+0x42/0x130
[74412.600957]  __netif_rx+0x20/0xd0
[74412.604743]  ntb_netdev_rx_handler+0x66/0x150 [ntb_netdev]
[74412.610985]  ntb_complete_rxc+0xed/0x140 [ntb_transport]
[74412.617010]  ntb_rx_copy_callback+0x53/0x80 [ntb_transport]
[74412.623332]  idxd_dma_complete_txd+0xe3/0x160 [idxd]
[74412.628963]  idxd_wq_thread+0x1a6/0x2b0 [idxd]
[74412.634046]  irq_thread_fn+0x21/0x60
[74412.638134]  ? irq_thread+0xa8/0x290
[74412.642218]  irq_thread+0x1a0/0x290
[74412.646212]  ? __pfx_irq_thread_fn+0x10/0x10
[74412.651071]  ? __pfx_irq_thread_dtor+0x10/0x10
[74412.656117]  ? __pfx_irq_thread+0x10/0x10
[74412.660686]  kthread+0x100/0x130
[74412.664384]  ? __pfx_kthread+0x10/0x10
[74412.668639]  ret_from_fork+0x31/0x50
[74412.672716]  ? __pfx_kthread+0x10/0x10
[74412.676978]  ret_from_fork_asm+0x1a/0x30
[74412.681457]  &lt;/TASK&gt;

The cause is due to the idxd driver interrupt completion handler uses
threaded interrupt and the threaded handler is not hard or soft interrupt
context. However __netif_rx() can only be called from interrupt context.
Change the call to netif_rx() in order to allow completion via normal
context for dmaengine drivers that utilize threaded irq handling.

While the following commit changed from netif_rx() to __netif_rx(),
baebdf48c360 ("net: dev: Makes sure netif_rx() can be invoked in any context."),
the change should've been a noop instead. However, the code precedes this
fix should've been using netif_rx_ni() or netif_rx_any_context().</Note>
    </Notes>
    <CVE>CVE-2024-42110</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values

syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM
to 2^31.

We had a similar issue in sch_fq, fixed with commit
d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")

watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]
Modules linked in:
irq event stamp: 131135
 hardirqs last  enabled at (131134): [&lt;ffff80008ae8778c&gt;] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]
 hardirqs last  enabled at (131134): [&lt;ffff80008ae8778c&gt;] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95
 hardirqs last disabled at (131135): [&lt;ffff80008ae85378&gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
 hardirqs last disabled at (131135): [&lt;ffff80008ae85378&gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
 softirqs last  enabled at (125892): [&lt;ffff80008907e82c&gt;] neigh_hh_init net/core/neighbour.c:1538 [inline]
 softirqs last  enabled at (125892): [&lt;ffff80008907e82c&gt;] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553
 softirqs last disabled at (125896): [&lt;ffff80008904166c&gt;] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19
CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Workqueue: mld mld_ifc_work
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : __list_del include/linux/list.h:195 [inline]
 pc : __list_del_entry include/linux/list.h:218 [inline]
 pc : list_move_tail include/linux/list.h:310 [inline]
 pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
 pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
 lr : __list_del_entry include/linux/list.h:218 [inline]
 lr : list_move_tail include/linux/list.h:310 [inline]
 lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
 lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854
sp : ffff800093d36700
x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000
x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0
x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0
x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0
x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8
x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff
x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc
x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470
Call trace:
  __list_del include/linux/list.h:195 [inline]
  __list_del_entry include/linux/list.h:218 [inline]
  list_move_tail include/linux/list.h:310 [inline]
  fq_tin_dequeue include/net/fq_impl.h:112 [inline]
  ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
  wake_tx_push_queue net/mac80211/util.c:294 [inline]
  ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315
  drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]
  schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]
  ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664
  ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966
  ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062
  __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338
  ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532
  __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
  netdev_start_xmit include/linux/netdevice.h:4917 [inline]
  xmit_one net/core/dev.c:3531 [inline]
  dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547
  __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341
  dev_queue_xmit include/linux/netdevice.h:3091 [inline]
  neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563
  neigh_output include/net/neighbour.h:542 [inline]
  ip6_fini
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-42114</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Skip finding free audio for unknown engine_id

[WHY]
ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it
also means it is uninitialized and does not need free audio.

[HOW]
Skip and return NULL.

This fixes 2 OVERRUN issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-42119</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check pipe offset before setting vblank

pipe_ctx has a size of MAX_PIPES so checking its index before accessing
the array.

This fixes an OVERRUN issue reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-42120</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: qedf: Make qedf_execute_tmf() non-preemptible

Stop calling smp_processor_id() from preemptible code in
qedf_execute_tmf90.  This results in BUG_ON() when running an RT kernel.

[ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646
[ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf]</Note>
    </Notes>
    <CVE>CVE-2024-42124</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: avoid overflows in dirty throttling logic

The dirty throttling logic is interspersed with assumptions that dirty
limits in PAGE_SIZE units fit into 32-bit (so that various multiplications
fit into 64-bits).  If limits end up being larger, we will hit overflows,
possible divisions by 0 etc.  Fix these problems by never allowing so
large dirty limits as they have dubious practical value anyway.  For
dirty_bytes / dirty_background_bytes interfaces we can just refuse to set
so large limits.  For dirty_ratio / dirty_background_ratio it isn't so
simple as the dirty limit is computed from the amount of available memory
which can change due to memory hotplug etc.  So when converting dirty
limits from ratios to numbers of pages, we just don't allow the result to
exceed UINT_MAX.

This is root-only triggerable problem which occurs when the operator
sets dirty limits to &gt;16 TB.</Note>
    </Notes>
    <CVE>CVE-2024-42131</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Implement a limit on UMAD receive List

The existing behavior of ib_umad, which maintains received MAD
packets in an unbounded list, poses a risk of uncontrolled growth.
As user-space applications extract packets from this list, the rate
of extraction may not match the rate of incoming packets, leading
to potential list overflow.

To address this, we introduce a limit to the size of the list. After
considering typical scenarios, such as OpenSM processing, which can
handle approximately 100k packets per second, and the 1-second retry
timeout for most packets, we set the list size limit to 200k. Packets
received beyond this limit are dropped, assuming they are likely timed
out by the time they are handled by user-space.

Notably, packets queued on the receive list due to reasons like
timed-out sends are preserved even when the list is full.</Note>
    </Notes>
    <CVE>CVE-2024-42145</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

bnx2x: Fix multiple UBSAN array-index-out-of-bounds

Fix UBSAN warnings that occur when using a system with 32 physical
cpu cores or more, or when the user defines a number of Ethernet
queues greater than or equal to FP_SB_MAX_E1x using the num_queues
module parameter.

Currently there is a read/write out of bounds that occurs on the array
"struct stats_query_entry query" present inside the "bnx2x_fw_stats_req"
struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h".
Looking at the definition of the "struct stats_query_entry query" array:

struct stats_query_entry query[FP_SB_MAX_E1x+
         BNX2X_FIRST_QUEUE_QUERY_IDX];

FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and
has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3
meaning the array has a total size of 19.
Since accesses to "struct stats_query_entry query" are offset-ted by
BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet
queues should not exceed FP_SB_MAX_E1x (16). However one of these queues
is reserved for FCOE and thus the number of Ethernet queues should be set
to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if
it is not.

This is also described in a comment in the source code in
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition
of FP_SB_MAX_E1x. Below is the part of this explanation that it important
for this patch

/*
  * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is
  * control by the number of fast-path status blocks supported by the
  * device (HW/FW). Each fast-path status block (FP-SB) aka non-default
  * status block represents an independent interrupts context that can
  * serve a regular L2 networking queue. However special L2 queues such
  * as the FCoE queue do not require a FP-SB and other components like
  * the CNIC may consume FP-SB reducing the number of possible L2 queues
  *
  * If the maximum number of FP-SB available is X then:
  * a. If CNIC is supported it consumes 1 FP-SB thus the max number of
  *    regular L2 queues is Y=X-1
  * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)
  * c. If the FCoE L2 queue is supported the actual number of L2 queues
  *    is Y+1
  * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for
  *    slow-path interrupts) or Y+2 if CNIC is supported (one additional
  *    FP interrupt context for the CNIC).
  * e. The number of HW context (CID count) is always X or X+1 if FCoE
  *    L2 queue is supported. The cid for the FCoE L2 queue is always X.
  */

However this driver also supports NICs that use the E2 controller which can
handle more queues due to having more FP-SB represented by FP_SB_MAX_E2.
Looking at the commits when the E2 support was added, it was originally
using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support").
Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver
was later updated to take full advantage of the E2 instead of having it be
limited to the capabilities of the E1x. But as far as we can tell, the
array "stats_query_entry query" was still limited to using the FP-SB
available to the E1x cards as part of an oversignt when the driver was
updated to take full advantage of the E2, and now with the driver being
aware of the greater queue size supported by E2 NICs, it causes the UBSAN
warnings seen in the stack traces below.

This patch increases the size of the "stats_query_entry query" array by
replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle
both types of NICs.

Stack traces:

UBSAN: array-index-out-of-bounds in
       drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11
index 20 is out of range for type 'stats_query_entry [19]'
CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic
	     #202405052133
Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-42148</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tcp_metrics: validate source addr length

I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4
is at least 4 bytes long, and the policy doesn't have an entry
for this attribute at all (neither does it for IPv6 but v6 is
manually validated).</Note>
    </Notes>
    <CVE>CVE-2024-42154</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pkey: Wipe copies of protected- and secure-keys

Although the clear-key of neither protected- nor secure-keys is
accessible, this key material should only be visible to the calling
process. So wipe all copies of protected- or secure-keys from stack,
even in case of an error.</Note>
    </Notes>
    <CVE>CVE-2024-42155</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pkey: Wipe sensitive data on failure

Wipe sensitive data from stack also if the copy_to_user() fails.</Note>
    </Notes>
    <CVE>CVE-2024-42157</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pkey: Use kfree_sensitive() to fix Coccinelle warnings

Replace memzero_explicit() and kfree() with kfree_sensitive() to fix
warnings reported by Coccinelle:

WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506)
WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643)
WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770)</Note>
    </Notes>
    <CVE>CVE-2024-42158</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gve: Account for stopped queues when reading NIC stats

We now account for the fact that the NIC might send us stats for a
subset of queues. Without this change, gve_get_ethtool_stats might make
an invalid access on the priv-&gt;stats_report-&gt;stats array.</Note>
    </Notes>
    <CVE>CVE-2024-42162</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: dvb-frontends: tda10048: Fix integer overflow

state-&gt;xtal_hz can be up to 16M, so it can overflow a 32 bit integer
when multiplied by pll_mfactor.

Create a new 64 bit variable to hold the calculations.</Note>
    </Notes>
    <CVE>CVE-2024-42223</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: dsa: mv88e6xxx: Correct check for empty list

Since commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO
busses") mv88e6xxx_default_mdio_bus() has checked that the
return value of list_first_entry() is non-NULL.

This appears to be intended to guard against the list chip-&gt;mdios being
empty.  However, it is not the correct check as the implementation of
list_first_entry is not designed to return NULL for empty lists.

Instead, use list_first_entry_or_null() which does return NULL if the
list is empty.

Flagged by Smatch.
Compile tested only.</Note>
    </Notes>
    <CVE>CVE-2024-42224</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-42226</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Using uninitialized value *size when calling amdgpu_vce_cs_reloc

Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.
V2: To really improve the handling we would actually
   need to have a separate value of 0xffffffff.(Christian)</Note>
    </Notes>
    <CVE>CVE-2024-42228</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: aead,cipher - zeroize key buffer after use

I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding
cryptographic information should be zeroized once they are no longer
needed. Accomplish this by using kfree_sensitive for buffers that
previously held the private key.</Note>
    </Notes>
    <CVE>CVE-2024-42229</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix race between delayed_work() and ceph_monc_stop()

The way the delayed work is handled in ceph_monc_stop() is prone to
races with mon_fault() and possibly also finish_hunting().  Both of
these can requeue the delayed work which wouldn't be canceled by any of
the following code in case that happens after cancel_delayed_work_sync()
runs -- __close_session() doesn't mess with the delayed work in order
to avoid interfering with the hunting interval logic.  This part was
missed in commit b5d91704f53e ("libceph: behave in mon_fault() if
cur_mon &lt; 0") and use-after-free can still ensue on monc and objects
that hang off of it, with monc-&gt;auth and monc-&gt;monmap being
particularly susceptible to quickly being reused.

To fix this:

- clear monc-&gt;cur_mon and monc-&gt;hunting as part of closing the session
  in ceph_monc_stop()
- bail from delayed_work() if monc-&gt;cur_mon is cleared, similar to how
  it's done in mon_fault() and finish_hunting() (based on monc-&gt;hunting)
- call cancel_delayed_work_sync() after the session is closed</Note>
    </Notes>
    <CVE>CVE-2024-42232</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()

Userspace provided string 's' could trivially have the length zero. Left
unchecked this will firstly result in an OOB read in the form
`if (str[0 - 1] == '\n') followed closely by an OOB write in the form
`str[0 - 1] = '\0'`.

There is already a validating check to catch strings that are too long.
Let's supply an additional check for invalid strings that are too short.</Note>
    </Notes>
    <CVE>CVE-2024-42236</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/bhi: Avoid warning in #DB handler due to BHI mitigation

When BHI mitigation is enabled, if SYSENTER is invoked with the TF flag set
then entry_SYSENTER_compat() uses CLEAR_BRANCH_HISTORY and calls the
clear_bhb_loop() before the TF flag is cleared. This causes the #DB handler
(exc_debug_kernel()) to issue a warning because single-step is used outside the
entry_SYSENTER_compat() function.

To address this issue, entry_SYSENTER_compat() should use CLEAR_BRANCH_HISTORY
after making sure the TF flag is cleared.

The problem can be reproduced with the following sequence:

  $ cat sysenter_step.c
  int main()
  { asm("pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter"); }

  $ gcc -o sysenter_step sysenter_step.c

  $ ./sysenter_step
  Segmentation fault (core dumped)

The program is expected to crash, and the #DB handler will issue a warning.

Kernel log:

  WARNING: CPU: 27 PID: 7000 at arch/x86/kernel/traps.c:1009 exc_debug_kernel+0xd2/0x160
  ...
  RIP: 0010:exc_debug_kernel+0xd2/0x160
  ...
  Call Trace:
  &lt;#DB&gt;
   ? show_regs+0x68/0x80
   ? __warn+0x8c/0x140
   ? exc_debug_kernel+0xd2/0x160
   ? report_bug+0x175/0x1a0
   ? handle_bug+0x44/0x90
   ? exc_invalid_op+0x1c/0x70
   ? asm_exc_invalid_op+0x1f/0x30
   ? exc_debug_kernel+0xd2/0x160
   exc_debug+0x43/0x50
   asm_exc_debug+0x1e/0x40
  RIP: 0010:clear_bhb_loop+0x0/0xb0
  ...
  &lt;/#DB&gt;
  &lt;TASK&gt;
   ? entry_SYSENTER_compat_after_hwframe+0x6e/0x8d
  &lt;/TASK&gt;

  [ bp: Massage commit message. ]</Note>
    </Notes>
    <CVE>CVE-2024-42240</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

USB: serial: mos7840: fix crash on resume

Since commit c49cfa917025 ("USB: serial: use generic method if no
alternative is provided in usb serial layer"), USB serial core calls the
generic resume implementation when the driver has not provided one.

This can trigger a crash on resume with mos7840 since support for
multiple read URBs was added back in 2011. Specifically, both port read
URBs are now submitted on resume for open ports, but the context pointer
of the second URB is left set to the core rather than mos7840 port
structure.

Fix this by implementing dedicated suspend and resume functions for
mos7840.

Tested with Delock 87414 USB 2.0 to 4x serial adapter.

[ johan: analyse crash and rewrite commit message; set busy flag on
         resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]</Note>
    </Notes>
    <CVE>CVE-2024-42244</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket

When using a BPF program on kernel_connect(), the call can return -EPERM. This
causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing
the kernel to potentially freeze up.

Neil suggested:

  This will propagate -EPERM up into other layers which might not be ready
  to handle it. It might be safer to map EPERM to an error we would be more
  likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.

ECONNREFUSED as error seems reasonable. For programs setting a different error
can be out of reach (see handling in 4fbac77d2d09) in particular on kernels
which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err
instead of allow boolean"), thus given that it is better to simply remap for
consistent behavior. UDP does handle EPERM in xs_udp_send_request().</Note>
    </Notes>
    <CVE>CVE-2024-42246</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pca953x: fix pca953x_irq_bus_sync_unlock race

Ensure that `i2c_lock' is held when setting interrupt latch and mask in
pca953x_irq_bus_sync_unlock() in order to avoid races.

The other (non-probe) call site pca953x_gpio_set_multiple() ensures the
lock is held before calling pca953x_write_regs().

The problem occurred when a request raced against irq_bus_sync_unlock()
approximately once per thousand reboots on an i.MX8MP based system.

 * Normal case

   0-0022: write register AI|3a {03,02,00,00,01} Input latch P0
   0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0
   0-0022: write register AI|08 {ff,00,00,00,00} Output P3
   0-0022: write register AI|12 {fc,00,00,00,00} Config P3

 * Race case

   0-0022: write register AI|08 {ff,00,00,00,00} Output P3
   0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register ***
   0-0022: write register AI|12 {fc,00,00,00,00} Config P3
   0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0</Note>
    </Notes>
    <CVE>CVE-2024-42253</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix Virtual Memory mapping boundaries calculation

Calculating the size of the mapped area as the lesser value
between the requested size and the actual size does not consider
the partial mapping offset. This can cause page fault access.

Fix the calculation of the starting and ending addresses, the
total size is now deduced from the difference between the end and
start addresses.

Additionally, the calculations have been rewritten in a clearer
and more understandable form.

[Joonas: Add Requires: tag]
Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset")
(cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)</Note>
    </Notes>
    <CVE>CVE-2024-42259</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

protect the fetch of -&gt;fd[fd] in do_dup2() from mispredictions

both callers have verified that fd is not greater than -&gt;max_fds;
however, misprediction might end up with
        tofree = fdt-&gt;fd[fd];
being speculatively executed.  That's wrong for the same reasons
why it's wrong in close_fd()/file_close_fd_locked(); the same
solution applies - array_index_nospec(fd, fdt-&gt;max_fds) could differ
from fd only in case of speculative execution on mispredicted path.</Note>
    </Notes>
    <CVE>CVE-2024-42265</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/iucv: fix use after free in iucv_sock_close()

iucv_sever_path() is called from process context and from bh context.
iucv-&gt;path is used as indicator whether somebody else is taking care of
severing the path (or it is already removed / never existed).
This needs to be done with atomic compare and swap, otherwise there is a
small window where iucv_sock_close() will try to work with a path that has
already been severed and freed by iucv_callback_connrej() called by
iucv_tasklet_fn().

Example:
[452744.123844] Call Trace:
[452744.123845] ([&lt;0000001e87f03880&gt;] 0x1e87f03880)
[452744.123966]  [&lt;00000000d593001e&gt;] iucv_path_sever+0x96/0x138
[452744.124330]  [&lt;000003ff801ddbca&gt;] iucv_sever_path+0xc2/0xd0 [af_iucv]
[452744.124336]  [&lt;000003ff801e01b6&gt;] iucv_sock_close+0xa6/0x310 [af_iucv]
[452744.124341]  [&lt;000003ff801e08cc&gt;] iucv_sock_release+0x3c/0xd0 [af_iucv]
[452744.124345]  [&lt;00000000d574794e&gt;] __sock_release+0x5e/0xe8
[452744.124815]  [&lt;00000000d5747a0c&gt;] sock_close+0x34/0x48
[452744.124820]  [&lt;00000000d5421642&gt;] __fput+0xba/0x268
[452744.124826]  [&lt;00000000d51b382c&gt;] task_work_run+0xbc/0xf0
[452744.124832]  [&lt;00000000d5145710&gt;] do_notify_resume+0x88/0x90
[452744.124841]  [&lt;00000000d5978096&gt;] system_call+0xe2/0x2c8
[452744.125319] Last Breaking-Event-Address:
[452744.125321]  [&lt;00000000d5930018&gt;] iucv_path_sever+0x90/0x138
[452744.125324]
[452744.125325] Kernel panic - not syncing: Fatal exception in interrupt

Note that bh_lock_sock() is not serializing the tasklet context against
process context, because the check for sock_owned_by_user() and
corresponding handling is missing.

Ideas for a future clean-up patch:
A) Correct usage of bh_lock_sock() in tasklet context, as described in
Re-enqueue, if needed. This may require adding return values to the
tasklet functions and thus changes to all users of iucv.

B) Change iucv tasklet into worker and use only lock_sock() in af_iucv.</Note>
    </Notes>
    <CVE>CVE-2024-42271</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

mISDN: Fix a use after free in hfcmulti_tx()

Don't dereference *sp after calling dev_kfree_skb(*sp).</Note>
    </Notes>
    <CVE>CVE-2024-42280</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 a segment issue when downgrading gso_size

Linearize the skb when downgrading gso_size because it may trigger a
BUG_ON() later when the skb is segmented as described in [1,2].</Note>
    </Notes>
    <CVE>CVE-2024-42281</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tipc: Return non-zero value from tipc_udp_addr2str() on error

tipc_udp_addr2str() should return non-zero value if the UDP media
address is invalid. Otherwise, a buffer overflow access can occur in
tipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP
media address.</Note>
    </Notes>
    <CVE>CVE-2024-42284</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/iwcm: Fix a use-after-free related to destroying CM IDs

iw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with
an existing struct iw_cm_id (cm_id) as follows:

        conn_id-&gt;cm_id.iw = cm_id;
        cm_id-&gt;context = conn_id;
        cm_id-&gt;cm_handler = cma_iw_handler;

rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make
sure that cm_work_handler() does not trigger a use-after-free by only
freeing of the struct rdma_id_private after all pending work has finished.</Note>
    </Notes>
    <CVE>CVE-2024-42285</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: validate nvme_local_port correctly

The driver load failed with error message,

qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef

and with a kernel crash,

	BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
	Workqueue: events_unbound qla_register_fcport_fn [qla2xxx]
	RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]
	RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282
	RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000
	RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000
	RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030
	R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4
	R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8
	FS:  0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000
	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
	CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0
	Call Trace:
	qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]
	? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]
	qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]
	qla_register_fcport_fn+0x54/0xc0 [qla2xxx]

Exit the qla_nvme_register_remote() function when qla_nvme_register_hba()
fails and correctly validate nvme_local_port.</Note>
    </Notes>
    <CVE>CVE-2024-42286</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Complete command early within lock

A crash was observed while performing NPIV and FW reset,

 BUG: kernel NULL pointer dereference, address: 000000000000001c
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 1 PREEMPT_RT SMP NOPTI
 RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0
 RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246
 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002
 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0
 RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034
 R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000
 R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000
 FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000
 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 PKRU: 55555554
 Call Trace:
 &lt;TASK&gt;
 ? __die_body+0x1a/0x60
 ? page_fault_oops+0x16f/0x4a0
 ? do_user_addr_fault+0x174/0x7f0
 ? exc_page_fault+0x69/0x1a0
 ? asm_exc_page_fault+0x22/0x30
 ? dma_direct_unmap_sg+0x51/0x1e0
 ? preempt_count_sub+0x96/0xe0
 qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx]
 qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx]
 __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx]

The command completion was done early while aborting the commands in driver
unload path but outside lock to avoid the WARN_ON condition of performing
dma_free_attr within the lock. However this caused race condition while
command completion via multiple paths causing system crash.

Hence complete the command early in unload path but within the lock to
avoid race condition.</Note>
    </Notes>
    <CVE>CVE-2024-42287</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 for possible memory corruption

Init Control Block is dereferenced incorrectly.  Correctly dereference ICB</Note>
    </Notes>
    <CVE>CVE-2024-42288</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: During vport delete send async logout explicitly

During vport delete, it is observed that during unload we hit a crash
because of stale entries in outstanding command array.  For all these stale
I/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but
I/Os could not complete while vport delete is in process of deleting.

  BUG: kernel NULL pointer dereference, address: 000000000000001c
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] PREEMPT SMP NOPTI
  Workqueue: qla2xxx_wq qla_do_work [qla2xxx]
  RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0
  RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046
  RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001
  RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0
  RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8
  R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000
  R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000
  FS:  0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0
  Call Trace:
  &lt;TASK&gt;
  qla2xxx_qpair_sp_free_dma+0x417/0x4e0
  ? qla2xxx_qpair_sp_compl+0x10d/0x1a0
  ? qla2x00_status_entry+0x768/0x2830
  ? newidle_balance+0x2f0/0x430
  ? dequeue_entity+0x100/0x3c0
  ? qla24xx_process_response_queue+0x6a1/0x19e0
  ? __schedule+0x2d5/0x1140
  ? qla_do_work+0x47/0x60
  ? process_one_work+0x267/0x440
  ? process_one_work+0x440/0x440
  ? worker_thread+0x2d/0x3d0
  ? process_one_work+0x440/0x440
  ? kthread+0x156/0x180
  ? set_kthread_struct+0x50/0x50
  ? ret_from_fork+0x22/0x30
  &lt;/TASK&gt;

Send out async logout explicitly for all the ports during vport delete.</Note>
    </Notes>
    <CVE>CVE-2024-42289</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dev/parport: fix the array out-of-bounds risk

Fixed array out-of-bounds issues caused by sprintf
by replacing it with snprintf for safer data copying,
ensuring the destination buffer is not overflowed.

Below is the stack trace I encountered during the actual issue:

[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:
Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]
[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:
QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2
[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp
[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun
PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024
[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:
[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0
[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20
[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c
[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc
[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38
[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport]</Note>
    </Notes>
    <CVE>CVE-2024-42301</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: check dot and dotdot of dx_root before making dir indexed

Syzbot reports a issue as follows:
============================================
BUG: unable to handle page fault for address: ffffed11022e24fe
PGD 23ffee067 P4D 23ffee067 PUD 0
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0
Call Trace:
 &lt;TASK&gt;
 make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341
 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451
 ext4_rename fs/ext4/namei.c:3936 [inline]
 ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214
[...]
============================================

The immediate cause of this problem is that there is only one valid dentry
for the block to be split during do_split, so split==0 results in out of
bounds accesses to the map triggering the issue.

    do_split
      unsigned split
      dx_make_map
       count = 1
      split = count/2 = 0;
      continued = hash2 == map[split - 1].hash;
       ---&gt; map[4294967295]

The maximum length of a filename is 255 and the minimum block size is 1024,
so it is always guaranteed that the number of entries is greater than or
equal to 2 when do_split() is called.

But syzbot's crafted image has no dot and dotdot in dir, and the dentry
distribution in dirblock is as follows:

  bus     dentry1          hole           dentry2           free
|xx--|xx-------------|...............|xx-------------|...............|
0   12 (8+248)=256  268     256     524 (8+256)=264 788     236     1024

So when renaming dentry1 increases its name_len length by 1, neither hole
nor free is sufficient to hold the new dentry, and make_indexed_dir() is
called.

In make_indexed_dir() it is assumed that the first two entries of the
dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root
because they are treated as dot and dotdot, and only dentry2 is moved
to the new leaf block. That's why count is equal to 1.

Therefore add the ext4_check_dx_root() helper function to add more sanity
checks to dot and dotdot before starting the conversion to avoid the above
issue.</Note>
    </Notes>
    <CVE>CVE-2024-42305</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

udf: Avoid using corrupted block bitmap buffer

When the filesystem block bitmap is corrupted, we detect the corruption
while loading the bitmap and fail the allocation with error. However the
next allocation from the same bitmap will notice the bitmap buffer is
already loaded and tries to allocate from the bitmap with mixed results
(depending on the exact nature of the bitmap corruption). Fix the
problem by using BH_verified bit to indicate whether the bitmap is valid
or not.</Note>
    </Notes>
    <CVE>CVE-2024-42306</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes

In psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is
assigned to mode, which will lead to a possible NULL pointer dereference
on failure of drm_mode_duplicate(). Add a check to avoid npd.</Note>
    </Notes>
    <CVE>CVE-2024-42309</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes

In cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a NULL pointer dereference on
failure of drm_mode_duplicate(). Add a check to avoid npd.</Note>
    </Notes>
    <CVE>CVE-2024-42310</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sysctl: always initialize i_uid/i_gid

Always initialize i_uid/i_gid inside the sysfs core so set_ownership()
can safely skip setting them.

Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of
i_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid when
set_ownership() was not implemented. It also missed adjusting
net_ctl_set_ownership() to use the same default values in case the
computation of a better value failed.</Note>
    </Notes>
    <CVE>CVE-2024-42312</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipvs: properly dereference pe in ip_vs_add_service

Use pe directly to resolve sparse warning:

  net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression</Note>
    </Notes>
    <CVE>CVE-2024-42322</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The UNIX editor Vim prior to version 9.1.0678 has a use-after-free error in argument list handling. When adding a new file to the argument list, this triggers `Buf*` autocommands. If in such an autocommand the buffer that was just opened is closed (including the window where it is shown), this causes the window structure to be freed which contains a reference to the argument list that we are actually modifying. Once the autocommands are completed, the references to the window and argument list are no longer valid and as such cause an use-after-free. Impact is low since the user must either intentionally add some unusual autocommands that wipe a buffer during creation (either manually or by sourcing a malicious plugin), but it will crash Vim. The issue has been fixed as of Vim patch v9.1.0678.</Note>
    </Notes>
    <CVE>CVE-2024-43374</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:vim-9.1.0836-17.38.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:vim-data-common-9.1.0836-17.38.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

kvm: s390: Reject memory region operations for ucontrol VMs

This change rejects the KVM_SET_USER_MEMORY_REGION and
KVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM.
This is necessary since ucontrol VMs have kvm-&gt;arch.gmap set to 0 and
would thus result in a null pointer dereference further in.
Memory management needs to be performed in userspace and using the
ioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP.

Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGION
and KVM_SET_USER_MEMORY_REGION2.

[frankja@linux.ibm.com: commit message spelling fix, subject prefix fix]</Note>
    </Notes>
    <CVE>CVE-2024-43819</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mediatek: vcodec: Handle invalid decoder vsi

Handle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsi
is valid for future use.</Note>
    </Notes>
    <CVE>CVE-2024-43831</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bna: adjust 'name' buf size of bna_tcb and bna_ccb structures

To have enough space to write all possible sprintf() args. Currently
'name' size is 16, but the first '%s' specifier may already need at
least 16 characters, since 'bnad-&gt;netdev-&gt;name' is used there.

For '%d' specifiers, assume that they require:
 * 1 char for 'tx_id + tx_info-&gt;tcb[i]-&gt;id' sum, BNAD_MAX_TXQ_PER_TX is 8
 * 2 chars for 'rx_id + rx_info-&gt;rx_ctrl[i].ccb-&gt;id', BNAD_MAX_RXP_PER_RX
   is 16

And replace sprintf with snprintf.

Detected using the static analysis tool - Svace.</Note>
    </Notes>
    <CVE>CVE-2024-43839</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/cpuset: Prevent UAF in proc_cpuset_show()

An UAF can happen when /proc/cpuset is read as reported in [1].

This can be reproduced by the following methods:
1.add an mdelay(1000) before acquiring the cgroup_lock In the
 cgroup_path_ns function.
2.$cat /proc/&lt;pid&gt;/cpuset   repeatly.
3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/
$umount /sys/fs/cgroup/cpuset/   repeatly.

The race that cause this bug can be shown as below:

(umount)		|	(cat /proc/&lt;pid&gt;/cpuset)
css_release		|	proc_cpuset_show
css_release_work_fn	|	css = task_get_css(tsk, cpuset_cgrp_id);
css_free_rwork_fn	|	cgroup_path_ns(css-&gt;cgroup, ...);
cgroup_destroy_root	|	mutex_lock(&amp;cgroup_mutex);
rebind_subsystems	|
cgroup_free_root 	|
			|	// cgrp was freed, UAF
			|	cgroup_path_ns_locked(cgrp,..);

When the cpuset is initialized, the root node top_cpuset.css.cgrp
will point to &amp;cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will
allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated
&amp;cgroup_root.cgrp. When the umount operation is executed,
top_cpuset.css.cgrp will be rebound to &amp;cgrp_dfl_root.cgrp.

The problem is that when rebinding to cgrp_dfl_root, there are cases
where the cgroup_root allocated by setting up the root for cgroup v1
is cached. This could lead to a Use-After-Free (UAF) if it is
subsequently freed. The descendant cgroups of cgroup v1 can only be
freed after the css is released. However, the css of the root will never
be released, yet the cgroup_root should be freed when it is unmounted.
This means that obtaining a reference to the css of the root does
not guarantee that css.cgrp-&gt;root will not be freed.

Fix this problem by using rcu_read_lock in proc_cpuset_show().
As cgroup_root is kfree_rcu after commit d23b5c577715
("cgroup: Make operations on the cgroup root_list RCU safe"),
css-&gt;cgroup won't be freed during the critical section.
To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to
replace task_get_css with task_css.

[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd</Note>
    </Notes>
    <CVE>CVE-2024-43853</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

block: initialize integrity buffer to zero before writing it to media

Metadata added by bio_integrity_prep is using plain kmalloc, which leads
to random kernel memory being written media.  For PI metadata this is
limited to the app tag that isn't used by kernel generated metadata,
but for non-PI metadata the entire buffer leaks kernel memory.

Fix this by adding the __GFP_ZERO flag to allocations for writes.</Note>
    </Notes>
    <CVE>CVE-2024-43854</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dma: fix call order in dmam_free_coherent

dmam_free_coherent() frees a DMA allocation, which makes the
freed vaddr available for reuse, then calls devres_destroy()
to remove and free the data structure used to track the DMA
allocation. Between the two calls, it is possible for a
concurrent task to make an allocation with the same vaddr
and add it to the devres list.

If this happens, there will be two entries in the devres list
with the same vaddr and devres_destroy() can free the wrong
entry, triggering the WARN_ON() in dmam_match.

Fix by destroying the devres entry before freeing the DMA
allocation.

  kokonut //net/encryption
    http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03</Note>
    </Notes>
    <CVE>CVE-2024-43856</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: usb: qmi_wwan: fix memory leak for not ip packets

Free the unused skb when not ip packets arrive.</Note>
    </Notes>
    <CVE>CVE-2024-43861</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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/vmwgfx: Fix a deadlock in dma buf fence polling

Introduce a version of the fence ops that on release doesn't remove
the fence from the pending list, and thus doesn't require a lock to
fix poll-&gt;fence wait-&gt;fence unref deadlocks.

vmwgfx overwrites the wait callback to iterate over the list of all
fences and update their status, to do that it holds a lock to prevent
the list modifcations from other threads. The fence destroy callback
both deletes the fence and removes it from the list of pending
fences, for which it holds a lock.

dma buf polling cb unrefs a fence after it's been signaled: so the poll
calls the wait, which signals the fences, which are being destroyed.
The destruction tries to acquire the lock on the pending fences list
which it can never get because it's held by the wait from which it
was called.

Old bug, but not a lot of userspace apps were using dma-buf polling
interfaces. Fix those, in particular this fixes KDE stalls/deadlock.</Note>
    </Notes>
    <CVE>CVE-2024-43863</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Always drain health in shutdown callback

There is no point in recovery during device shutdown. if health
work started need to wait for it to avoid races and NULL pointer
access.

Hence, drain health WQ on shutdown callback.</Note>
    </Notes>
    <CVE>CVE-2024-43866</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

devres: Fix memory leakage caused by driver API devm_free_percpu()

It will cause memory leakage when use driver API devm_free_percpu()
to free memory allocated by devm_alloc_percpu(), fixed by using
devres_release() instead of devres_destroy() within devm_free_percpu().</Note>
    </Notes>
    <CVE>CVE-2024-43871</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/hns: Fix soft lockup under heavy CEQE load

CEQEs are handled in interrupt handler currently. This may cause the
CPU core staying in interrupt context too long and lead to soft lockup
under heavy load.

Handle CEQEs in BH workqueue and set an upper limit for the number of
CEQE handled by a single call of work handler.</Note>
    </Notes>
    <CVE>CVE-2024-43872</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()

Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in
cfg80211_calculate_bitrate_he(), leading to below warning:

kernel: invalid HE MCS: bw:6, ru:6
kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]

Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.</Note>
    </Notes>
    <CVE>CVE-2024-43879</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

exec: Fix ToCToU between perm check and set-uid/gid usage

When opening a file for exec via do_filp_open(), permission checking is
done against the file's metadata at that moment, and on success, a file
pointer is passed back. Much later in the execve() code path, the file
metadata (specifically mode, uid, and gid) is used to determine if/how
to set the uid and gid. However, those values may have changed since the
permissions check, meaning the execution may gain unintended privileges.

For example, if a file could change permissions from executable and not
set-id:

---------x 1 root root 16048 Aug  7 13:16 target

to set-id and non-executable:

---S------ 1 root root 16048 Aug  7 13:16 target

it is possible to gain root privileges when execution should have been
disallowed.

While this race condition is rare in real-world scenarios, it has been
observed (and proven exploitable) when package managers are updating
the setuid bits of installed programs. Such files start with being
world-executable but then are adjusted to be group-exec with a set-uid
bit. For example, "chmod o-x,u+s target" makes "target" executable only
by uid "root" and gid "cdrom", while also becoming setuid-root:

-rwxr-xr-x 1 root cdrom 16048 Aug  7 13:16 target

becomes:

-rwsr-xr-- 1 root cdrom 16048 Aug  7 13:16 target

But racing the chmod means users without group "cdrom" membership can
get the permission to execute "target" just before the chmod, and when
the chmod finishes, the exec reaches brpm_fill_uid(), and performs the
setuid to root, violating the expressed authorization of "only cdrom
group members can setuid to root".

Re-check that we still have execute permissions in case the metadata
has changed. It would be better to keep a copy from the perm-check time,
but until we can do that refactoring, the least-bad option is to do a
full inode_permission() call (under inode lock). It is understood that
this is safe against dead-locks, but hardly optimal.</Note>
    </Notes>
    <CVE>CVE-2024-43882</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: vhci-hcd: Do not drop references before new references are gained

At a few places the driver carries stale pointers
to references that can still be used. Make sure that does not happen.
This strictly speaking closes ZDI-CAN-22273, though there may be
similar races in the driver.</Note>
    </Notes>
    <CVE>CVE-2024-43883</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: MGMT: Add error handling to pair_device()

hci_conn_params_add() never checks for a NULL value and could lead to a NULL
pointer dereference causing a crash.

Fixed by adding error handling in the function.</Note>
    </Notes>
    <CVE>CVE-2024-43884</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tracing: Fix overflow in get_free_elt()

"tracing_map-&gt;next_elt" in get_free_elt() is at risk of overflowing.

Once it overflows, new elements can still be inserted into the tracing_map
even though the maximum number of elements (`max_elts`) has been reached.
Continuing to insert elements after the overflow could result in the
tracing_map containing "tracing_map-&gt;max_size" elements, leaving no empty
entries.
If any attempt is made to insert an element into a full tracing_map using
`__tracing_map_insert()`, it will cause an infinite loop with preemption
disabled, leading to a CPU hang problem.

Fix this by preventing any further increments to "tracing_map-&gt;next_elt"
once it reaches "tracing_map-&gt;max_elt".</Note>
    </Notes>
    <CVE>CVE-2024-43890</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

memcg: protect concurrent access to mem_cgroup_idr

Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after
many small jobs") decoupled the memcg IDs from the CSS ID space to fix the
cgroup creation failures.  It introduced IDR to maintain the memcg ID
space.  The IDR depends on external synchronization mechanisms for
modifications.  For the mem_cgroup_idr, the idr_alloc() and idr_replace()
happen within css callback and thus are protected through cgroup_mutex
from concurrent modifications.  However idr_remove() for mem_cgroup_idr
was not protected against concurrency and can be run concurrently for
different memcgs when they hit their refcnt to zero.  Fix that.

We have been seeing list_lru based kernel crashes at a low frequency in
our fleet for a long time.  These crashes were in different part of
list_lru code including list_lru_add(), list_lru_del() and reparenting
code.  Upon further inspection, it looked like for a given object (dentry
and inode), the super_block's list_lru didn't have list_lru_one for the
memcg of that object.  The initial suspicions were either the object is
not allocated through kmem_cache_alloc_lru() or somehow
memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but
returned success.  No evidence were found for these cases.

Looking more deeply, we started seeing situations where valid memcg's id
is not present in mem_cgroup_idr and in some cases multiple valid memcgs
have same id and mem_cgroup_idr is pointing to one of them.  So, the most
reasonable explanation is that these situations can happen due to race
between multiple idr_remove() calls or race between
idr_alloc()/idr_replace() and idr_remove().  These races are causing
multiple memcgs to acquire the same ID and then offlining of one of them
would cleanup list_lrus on the system for all of them.  Later access from
other memcgs to the list_lru cause crashes due to missing list_lru_one.</Note>
    </Notes>
    <CVE>CVE-2024-43892</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: check uartclk for zero to avoid divide by zero

Calling ioctl TIOCSSERIAL with an invalid baud_base can
result in uartclk being zero, which will result in a
divide by zero error in uart_get_divisor(). The check for
uartclk being zero in uart_set_info() needs to be done
before other settings are made as subsequent calls to
ioctl TIOCSSERIAL for the same port would be impacted if
the uartclk check was done where uartclk gets set.

Oops: divide error: 0000  PREEMPT SMP KASAN PTI
RIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580)
Call Trace:
 &lt;TASK&gt;
serial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576
    drivers/tty/serial/8250/8250_port.c:2589)
serial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502
    drivers/tty/serial/8250/8250_port.c:2741)
serial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862)
uart_change_line_settings (./include/linux/spinlock.h:376
    ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222)
uart_port_startup (drivers/tty/serial/serial_core.c:342)
uart_startup (drivers/tty/serial/serial_core.c:368)
uart_set_info (drivers/tty/serial/serial_core.c:1034)
uart_set_info_user (drivers/tty/serial/serial_core.c:1059)
tty_set_serial (drivers/tty/tty_io.c:2637)
tty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791)
__x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907
    fs/ioctl.c:893 fs/ioctl.c:893)
do_syscall_64 (arch/x86/entry/common.c:52
    (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

Rule: add</Note>
    </Notes>
    <CVE>CVE-2024-43893</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-43898</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: xc2028: avoid use-after-free in load_firmware_cb()

syzkaller reported use-after-free in load_firmware_cb() [1].
The reason is because the module allocated a struct tuner in tuner_probe(),
and then the module initialization failed, the struct tuner was released.
A worker which created during module initialization accesses this struct
tuner later, it caused use-after-free.

The process is as follows:

task-6504           worker_thread
tuner_probe                             &lt;= alloc dvb_frontend [2]
...
request_firmware_nowait                 &lt;= create a worker
...
tuner_remove                            &lt;= free dvb_frontend
...
                    request_firmware_work_func  &lt;= the firmware is ready
                    load_firmware_cb    &lt;= but now the dvb_frontend has been freed

To fix the issue, check the dvd_frontend in load_firmware_cb(), if it is
null, report a warning and just return.

[1]:
    ==================================================================
     BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0
     Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504

     Call trace:
      load_firmware_cb+0x1310/0x17a0
      request_firmware_work_func+0x128/0x220
      process_one_work+0x770/0x1824
      worker_thread+0x488/0xea0
      kthread+0x300/0x430
      ret_from_fork+0x10/0x20

     Allocated by task 6504:
      kzalloc
      tuner_probe+0xb0/0x1430
      i2c_device_probe+0x92c/0xaf0
      really_probe+0x678/0xcd0
      driver_probe_device+0x280/0x370
      __device_attach_driver+0x220/0x330
      bus_for_each_drv+0x134/0x1c0
      __device_attach+0x1f4/0x410
      device_initial_probe+0x20/0x30
      bus_probe_device+0x184/0x200
      device_add+0x924/0x12c0
      device_register+0x24/0x30
      i2c_new_device+0x4e0/0xc44
      v4l2_i2c_new_subdev_board+0xbc/0x290
      v4l2_i2c_new_subdev+0xc8/0x104
      em28xx_v4l2_init+0x1dd0/0x3770

     Freed by task 6504:
      kfree+0x238/0x4e4
      tuner_remove+0x144/0x1c0
      i2c_device_remove+0xc8/0x290
      __device_release_driver+0x314/0x5fc
      device_release_driver+0x30/0x44
      bus_remove_device+0x244/0x490
      device_del+0x350/0x900
      device_unregister+0x28/0xd0
      i2c_unregister_device+0x174/0x1d0
      v4l2_device_unregister+0x224/0x380
      em28xx_v4l2_init+0x1d90/0x3770

     The buggy address belongs to the object at ffff8000d7ca2000
      which belongs to the cache kmalloc-2k of size 2048
     The buggy address is located 776 bytes inside of
      2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)
     The buggy address belongs to the page:
     page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0
     flags: 0x7ff800000000100(slab)
     raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000
     raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
     page dumped because: kasan: bad access detected

     Memory state around the buggy address:
      ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     &gt;ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                           ^
      ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ==================================================================

[2]
    Actually, it is allocated for struct tuner, and dvb_frontend is inside.</Note>
    </Notes>
    <CVE>CVE-2024-43900</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 null checker before passing variables

Checks null pointer before passing variables to functions.

This fixes 3 NULL_RETURNS issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-43902</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pm: Fix the null pointer dereference for vega10_hwmgr

Check return value and conduct null pointer handling to avoid null pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2024-43905</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pm: Fix the null pointer dereference in apply_state_adjust_rules

Check the pointer value to fix potential null pointer
dereference</Note>
    </Notes>
    <CVE>CVE-2024-43907</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: nl80211: disallow setting special AP channel widths

Setting the AP channel width is meant for use with the normal
20/40/... MHz channel width progression, and switching around
in S1G or narrow channels isn't supported. Disallow that.</Note>
    </Notes>
    <CVE>CVE-2024-43912</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

md/raid5: avoid BUG_ON() while continue reshape after reassembling

Currently, mdadm support --revert-reshape to abort the reshape while
reassembling, as the test 07revert-grow. However, following BUG_ON()
can be triggerred by the test:

kernel BUG at drivers/md/raid5.c:6278!
invalid opcode: 0000 [#1] PREEMPT SMP PTI
irq event stamp: 158985
CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94
RIP: 0010:reshape_request+0x3f1/0xe60
Call Trace:
 &lt;TASK&gt;
 raid5_sync_request+0x43d/0x550
 md_do_sync+0xb7a/0x2110
 md_thread+0x294/0x2b0
 kthread+0x147/0x1c0
 ret_from_fork+0x59/0x70
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;

Root cause is that --revert-reshape update the raid_disks from 5 to 4,
while reshape position is still set, and after reassembling the array,
reshape position will be read from super block, then during reshape the
checking of 'writepos' that is caculated by old reshape position will
fail.

Fix this panic the easy way first, by converting the BUG_ON() to
WARN_ON(), and stop the reshape if checkings fail.

Noted that mdadm must fix --revert-shape as well, and probably md/raid
should enhance metadata validation as well, however this means
reassemble will fail and there must be user tools to fix the wrong
metadata.</Note>
    </Notes>
    <CVE>CVE-2024-43914</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: prevent potential speculation leaks in gpio_device_get_desc()

Userspace may trigger a speculative read of an address outside the gpio
descriptor array.
Users can do that by calling gpio_ioctl() with an offset out of range.
Offset is copied from user and then used as an array index to get
the gpio descriptor without sanitization in gpio_device_get_desc().

This change ensures that the offset is sanitized by using
array_index_nospec() to mitigate any possibility of speculative
information leaks.

This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.</Note>
    </Notes>
    <CVE>CVE-2024-44931</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

kcm: Serialise kcm_sendmsg() for the same socket.

syzkaller reported UAF in kcm_release(). [0]

The scenario is

  1. Thread A builds a skb with MSG_MORE and sets kcm-&gt;seq_skb.

  2. Thread A resumes building skb from kcm-&gt;seq_skb but is blocked
     by sk_stream_wait_memory()

  3. Thread B calls sendmsg() concurrently, finishes building kcm-&gt;seq_skb
     and puts the skb to the write queue

  4. Thread A faces an error and finally frees skb that is already in the
     write queue

  5. kcm_release() does double-free the skb in the write queue

When a thread is building a MSG_MORE skb, another thread must not touch it.

Let's add a per-sk mutex and serialise kcm_sendmsg().

[0]:
BUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline]
BUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline]
BUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]
BUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline]
BUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691
Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167

CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G    B              6.8.0-rc5-syzkaller-g9abbc24128bc #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Call trace:
 dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291
 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x178/0x518 mm/kasan/report.c:488
 kasan_report+0xd8/0x138 mm/kasan/report.c:601
 __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381
 __skb_unlink include/linux/skbuff.h:2366 [inline]
 __skb_dequeue include/linux/skbuff.h:2385 [inline]
 __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]
 __skb_queue_purge include/linux/skbuff.h:3181 [inline]
 kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691
 __sock_release net/socket.c:659 [inline]
 sock_close+0xa4/0x1e8 net/socket.c:1421
 __fput+0x30c/0x738 fs/file_table.c:376
 ____fput+0x20/0x30 fs/file_table.c:404
 task_work_run+0x230/0x2e0 kernel/task_work.c:180
 exit_task_work include/linux/task_work.h:38 [inline]
 do_exit+0x618/0x1f64 kernel/exit.c:871
 do_group_exit+0x194/0x22c kernel/exit.c:1020
 get_signal+0x1500/0x15ec kernel/signal.c:2893
 do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249
 do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148
 exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline]
 exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline]
 el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713
 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598

Allocated by task 6166:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x40/0x78 mm/kasan/common.c:68
 kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626
 unpoison_slab_object mm/kasan/common.c:314 [inline]
 __kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340
 kasan_slab_alloc include/linux/kasan.h:201 [inline]
 slab_post_alloc_hook mm/slub.c:3813 [inline]
 slab_alloc_node mm/slub.c:3860 [inline]
 kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903
 __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641
 alloc_skb include/linux/skbuff.h:1296 [inline]
 kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg net/socket.c:745 [inline]
 sock_sendmsg+0x220/0x2c0 net/socket.c:768
 splice_to_socket+0x7cc/0xd58 fs/splice.c:889
 do_splice_from fs/splice.c:941 [inline]
 direct_splice_actor+0xec/0x1d8 fs/splice.c:1164
 splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108
 do_splice_direct_actor 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-44946</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

fuse: Initialize beyond-EOF page contents before setting uptodate

fuse_notify_store(), unlike fuse_do_readpage(), does not enable page
zeroing (because it can be used to change partial page contents).

So fuse_notify_store() must be more careful to fully initialize page
contents (including parts of the page that are beyond end-of-file)
before marking the page uptodate.

The current code can leave beyond-EOF page contents uninitialized, which
makes these uninitialized page contents visible to userspace via mmap().

This is an information leak, but only affects systems which do not
enable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the
corresponding kernel command line parameter).</Note>
    </Notes>
    <CVE>CVE-2024-44947</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/mtrr: Check if fixed MTRRs exist before saving them

MTRRs have an obsolete fixed variant for fine grained caching control
of the 640K-1MB region that uses separate MSRs. This fixed variant has
a separate capability bit in the MTRR capability MSR.

So far all x86 CPUs which support MTRR have this separate bit set, so it
went unnoticed that mtrr_save_state() does not check the capability bit
before accessing the fixed MTRR MSRs.

Though on a CPU that does not support the fixed MTRR capability this
results in a #GP.  The #GP itself is harmless because the RDMSR fault is
handled gracefully, but results in a WARN_ON().

Add the missing capability check to prevent this.</Note>
    </Notes>
    <CVE>CVE-2024-44948</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix invalid FIFO access with special register set

When enabling access to the special register set, Receiver time-out and
RHR interrupts can happen. In this case, the IRQ handler will try to read
from the FIFO thru the RHR register at address 0x00, but address 0x00 is
mapped to DLL register, resulting in erroneous FIFO reading.

Call graph example:
    sc16is7xx_startup(): entry
    sc16is7xx_ms_proc(): entry
    sc16is7xx_set_termios(): entry
    sc16is7xx_set_baud(): DLH/DLL = $009C --&gt; access special register set
    sc16is7xx_port_irq() entry            --&gt; IIR is 0x0C
    sc16is7xx_handle_rx() entry
    sc16is7xx_fifo_read(): --&gt; unable to access FIFO (RHR) because it is
                               mapped to DLL (LCR=LCR_CONF_MODE_A)
    sc16is7xx_set_baud(): exit --&gt; Restore access to general register set

Fix the problem by claiming the efr_lock mutex when accessing the Special
register set.</Note>
    </Notes>
    <CVE>CVE-2024-44950</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-44952</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: line6: Fix racy access to midibuf

There can be concurrent accesses to line6 midibuf from both the URB
completion callback and the rawmidi API access.  This could be a cause
of KMSAN warning triggered by syzkaller below (so put as reported-by
here).

This patch protects the midibuf call of the former code path with a
spinlock for avoiding the possible races.</Note>
    </Notes>
    <CVE>CVE-2024-44954</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/smt: Fix unbalance sched_smt_present dec/inc

I got the following warn report while doing stress test:

jump label: negative count!
WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0
Call Trace:
 &lt;TASK&gt;
 __static_key_slow_dec_cpuslocked+0x16/0x70
 sched_cpu_deactivate+0x26e/0x2a0
 cpuhp_invoke_callback+0x3ad/0x10d0
 cpuhp_thread_fun+0x3f5/0x680
 smpboot_thread_fn+0x56d/0x8d0
 kthread+0x309/0x400
 ret_from_fork+0x41/0x70
 ret_from_fork_asm+0x1b/0x30
 &lt;/TASK&gt;

Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),
the cpu offline failed, but sched_smt_present is decremented before
calling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so
fix it by incrementing sched_smt_present in the error path.</Note>
    </Notes>
    <CVE>CVE-2024-44958</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/sclp: Prevent release of buffer in I/O

When a task waiting for completion of a Store Data operation is
interrupted, an attempt is made to halt this operation. If this attempt
fails due to a hardware or firmware problem, there is a chance that the
SCLP facility might store data into buffers referenced by the original
operation at a later time.

Handle this situation by not releasing the referenced data buffers if
the halt attempt fails. For current use cases, this might result in a
leak of few pages of memory in case of a rare hardware/firmware
malfunction.</Note>
    </Notes>
    <CVE>CVE-2024-44969</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/msm/dpu: cleanup FB if dpu_format_populate_layout fails

If the dpu_format_populate_layout() fails, then FB is prepared, but not
cleaned up. This ends up leaking the pin_count on the GEM object and
causes a splat during DRM file closure:

msm_obj-&gt;pin_count
WARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc
[...]
Call trace:
 update_lru_locked+0xc4/0xcc
 put_pages+0xac/0x100
 msm_gem_free_object+0x138/0x180
 drm_gem_object_free+0x1c/0x30
 drm_gem_object_handle_put_unlocked+0x108/0x10c
 drm_gem_object_release_handle+0x58/0x70
 idr_for_each+0x68/0xec
 drm_gem_release+0x28/0x40
 drm_file_free+0x174/0x234
 drm_release+0xb0/0x160
 __fput+0xc0/0x2c8
 __fput_sync+0x50/0x5c
 __arm64_sys_close+0x38/0x7c
 invoke_syscall+0x48/0x118
 el0_svc_common.constprop.0+0x40/0xe0
 do_el0_svc+0x1c/0x28
 el0_svc+0x4c/0x120
 el0t_64_sync_handler+0x100/0x12c
 el0t_64_sync+0x190/0x194
irq event stamp: 129818
hardirqs last  enabled at (129817): [&lt;ffffa5f6d953fcc0&gt;] console_unlock+0x118/0x124
hardirqs last disabled at (129818): [&lt;ffffa5f6da7dcf04&gt;] el1_dbg+0x24/0x8c
softirqs last  enabled at (129808): [&lt;ffffa5f6d94afc18&gt;] handle_softirqs+0x4c8/0x4e8
softirqs last disabled at (129785): [&lt;ffffa5f6d94105e4&gt;] __do_softirq+0x14/0x20

Patchwork: https://patchwork.freedesktop.org/patch/600714/</Note>
    </Notes>
    <CVE>CVE-2024-44982</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipv6: prevent UAF in ip6_send_skb()

syzbot reported an UAF in ip6_send_skb() [1]

After ip6_local_out() has returned, we no longer can safely
dereference rt, unless we hold rcu_read_lock().

A similar issue has been fixed in commit
a688caa34beb ("ipv6: take rcu lock in rawv6_send_hdrinc()")

Another potential issue in ip6_finish_output2() is handled in a
separate patch.

[1]
 BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964
Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530

CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:93 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
  print_address_description mm/kasan/report.c:377 [inline]
  print_report+0x169/0x550 mm/kasan/report.c:488
  kasan_report+0x143/0x180 mm/kasan/report.c:601
  ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964
  rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588
  rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x1a6/0x270 net/socket.c:745
  sock_write_iter+0x2dd/0x400 net/socket.c:1160
 do_iter_readv_writev+0x60a/0x890
  vfs_writev+0x37c/0xbb0 fs/read_write.c:971
  do_writev+0x1b1/0x350 fs/read_write.c:1018
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f936bf79e79
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79
RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004
RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8
 &lt;/TASK&gt;

Allocated by task 6530:
  kasan_save_stack mm/kasan/common.c:47 [inline]
  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
  unpoison_slab_object mm/kasan/common.c:312 [inline]
  __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338
  kasan_slab_alloc include/linux/kasan.h:201 [inline]
  slab_post_alloc_hook mm/slub.c:3988 [inline]
  slab_alloc_node mm/slub.c:4037 [inline]
  kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044
  dst_alloc+0x12b/0x190 net/core/dst.c:89
  ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670
  make_blackhole net/xfrm/xfrm_policy.c:3120 [inline]
  xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313
  ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257
  rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x1a6/0x270 net/socket.c:745
  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597
  ___sys_sendmsg net/socket.c:2651 [inline]
  __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 45:
  kasan_save_stack mm/kasan/common.c:47 [inline]
  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
  kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
  poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
  __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
  kasan_slab_free include/linux/kasan.h:184 [inline]
  slab_free_hook mm/slub.c:2252 [inline]
  slab_free mm/slub.c:4473 [inline]
  kmem_cache_free+0x145/0x350 mm/slub.c:4548
  dst_destroy+0x2ac/0x460 net/core/dst.c:124
  rcu_do_batch kernel/rcu/tree.c:2569 [inline]
  rcu_core+0xafd/0x1830 kernel/rcu/tree.
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-44987</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 a deadlock problem when config TC during resetting

When config TC during the reset process, may cause a deadlock, the flow is
as below:
                             pf reset start
                                 |
                                 ▼
                              ......
setup tc                         |
    |                            ▼
    ▼                      DOWN: napi_disable()
napi_disable()(skip)             |
    |                            |
    ▼                            ▼
  ......                      ......
    |                            |
    ▼                            |
napi_enable()                    |
                                 ▼
                           UINIT: netif_napi_del()
                                 |
                                 ▼
                              ......
                                 |
                                 ▼
                           INIT: netif_napi_add()
                                 |
                                 ▼
                              ......                 global reset start
                                 |                      |
                                 ▼                      ▼
                           UP: napi_enable()(skip)    ......
                                 |                      |
                                 ▼                      ▼
                              ......                 napi_disable()

In reset process, the driver will DOWN the port and then UINIT, in this
case, the setup tc process will UP the port before UINIT, so cause the
problem. Adds a DOWN process in UINIT to fix it.</Note>
    </Notes>
    <CVE>CVE-2024-44995</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

atm: idt77252: prevent use after free in dequeue_rx()

We can't dereference "skb" after calling vcc-&gt;push() because the skb
is released.</Note>
    </Notes>
    <CVE>CVE-2024-44998</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gtp: pull network headers in gtp_dev_xmit()

syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]

We must make sure the IPv4 or Ipv6 header is pulled in skb-&gt;head
before accessing fields in them.

Use pskb_inet_may_pull() to fix this issue.

[1]
BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]
 BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]
 BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281
  ipv6_pdp_find drivers/net/gtp.c:220 [inline]
  gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]
  gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281
  __netdev_start_xmit include/linux/netdevice.h:4913 [inline]
  netdev_start_xmit include/linux/netdevice.h:4922 [inline]
  xmit_one net/core/dev.c:3580 [inline]
  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596
  __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423
  dev_queue_xmit include/linux/netdevice.h:3105 [inline]
  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
  packet_snd net/packet/af_packet.c:3145 [inline]
  packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:745
  __sys_sendto+0x685/0x830 net/socket.c:2204
  __do_sys_sendto net/socket.c:2216 [inline]
  __se_sys_sendto net/socket.c:2212 [inline]
  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212
  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at:
  slab_post_alloc_hook mm/slub.c:3994 [inline]
  slab_alloc_node mm/slub.c:4037 [inline]
  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583
  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674
  alloc_skb include/linux/skbuff.h:1320 [inline]
  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526
  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815
  packet_alloc_skb net/packet/af_packet.c:2994 [inline]
  packet_snd net/packet/af_packet.c:3088 [inline]
  packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:745
  __sys_sendto+0x685/0x830 net/socket.c:2204
  __do_sys_sendto net/socket.c:2216 [inline]
  __se_sys_sendto net/socket.c:2212 [inline]
  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212
  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024</Note>
    </Notes>
    <CVE>CVE-2024-44999</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Input: MT - limit max slots

syzbot is reporting too large allocation at input_mt_init_slots(), for
num_slots is supplied from userspace using ioctl(UI_DEV_CREATE).

Since nobody knows possible max slots, this patch chose 1024.</Note>
    </Notes>
    <CVE>CVE-2024-45008</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netem: fix return value if duplicate enqueue fails

There is a bug in netem_enqueue() introduced by
commit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec")
that can lead to a use-after-free.

This commit made netem_enqueue() always return NET_XMIT_SUCCESS
when a packet is duplicated, which can cause the parent qdisc's q.qlen
to be mistakenly incremented. When this happens qlen_notify() may be
skipped on the parent during destruction, leaving a dangling pointer
for some classful qdiscs like DRR.

There are two ways for the bug happen:

- If the duplicated packet is dropped by rootq-&gt;enqueue() and then
  the original packet is also dropped.
- If rootq-&gt;enqueue() sends the duplicated packet to a different qdisc
  and the original packet is dropped.

In both cases NET_XMIT_SUCCESS is returned even though no packets
are enqueued at the netem qdisc.

The fix is to defer the enqueue of the duplicate packet until after
the original packet has been guaranteed to return NET_XMIT_SUCCESS.</Note>
    </Notes>
    <CVE>CVE-2024-45016</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">runc is a CLI tool for spawning and running containers according to the OCI specification. runc 1.1.13 and earlier, as well as 1.2.0-rc2 and earlier, can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with `os.MkdirAll`. While this could be used to create empty files, existing files would not be truncated. An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack's scope but the exact scope of protection hasn't been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3.

Some workarounds are available. Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual
user on the host (such as with rootless containers that don't use `/etc/sub[ug]id`), this in practice means that an attacker would only be able to create inodes in world-writable directories. A strict enough SELinux or AppArmor policy could in principle also restrict the scope if a specific label is applied to the runc runtime, though neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.</Note>
    </Notes>
    <CVE>CVE-2024-45310</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:runc-1.1.14-16.57.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">An issue was discovered in libexpat before 2.6.3. xmlparse.c does not reject a negative length for XML_ParseBuffer.</Note>
    </Notes>
    <CVE>CVE-2024-45490</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:expat-2.1.0-21.40.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libexpat1-2.1.0-21.40.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINT_MAX equals SIZE_MAX).</Note>
    </Notes>
    <CVE>CVE-2024-45491</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:expat-2.1.0-21.40.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libexpat1-2.1.0-21.40.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was discovered in libexpat before 2.6.3. nextScaffoldPart in xmlparse.c can have an integer overflow for m_groupSize on 32-bit platforms (where UINT_MAX equals SIZE_MAX).</Note>
    </Notes>
    <CVE>CVE-2024-45492</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:expat-2.1.0-21.40.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libexpat1-2.1.0-21.40.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: aacraid: Fix double-free on probe failure

aac_probe_one() calls hardware-specific init functions through the
aac_driver_ident::init pointer, all of which eventually call down to
aac_init_adapter().

If aac_init_adapter() fails after allocating memory for aac_dev::queues,
it frees the memory but does not clear that member.

After the hardware-specific init function returns an error,
aac_probe_one() goes down an error path that frees the memory pointed to
by aac_dev::queues, resulting.in a double-free.</Note>
    </Notes>
    <CVE>CVE-2024-46673</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3: core: Prevent USB core invalid event buffer address access

This commit addresses an issue where the USB core could access an
invalid event buffer address during runtime suspend, potentially causing
SMMU faults and other memory issues in Exynos platforms. The problem
arises from the following sequence.
        1. In dwc3_gadget_suspend, there is a chance of a timeout when
        moving the USB core to the halt state after clearing the
        run/stop bit by software.
        2. In dwc3_core_exit, the event buffer is cleared regardless of
        the USB core's status, which may lead to an SMMU faults and
        other memory issues. if the USB core tries to access the event
        buffer address.

To prevent this hardware quirk on Exynos platforms, this commit ensures
that the event buffer address is not cleared by software  when the USB
core is active during runtime suspend by checking its status before
clearing the buffer address.</Note>
    </Notes>
    <CVE>CVE-2024-46675</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pn533: Add poll mod list filling check

In case of im_protocols value is 1 and tm_protocols value is 0 this
combination successfully passes the check
'if (!im_protocols &amp;&amp; !tm_protocols)' in the nfc_start_poll().
But then after pn533_poll_create_mod_list() call in pn533_start_poll()
poll mod list will remain empty and dev-&gt;poll_mod_count will remain 0
which lead to division by zero.

Normally no im protocol has value 1 in the mask, so this combination is
not expected by driver. But these protocol values actually come from
userspace via Netlink interface (NFC_CMD_START_POLL operation). So a
broken or malicious program may pass a message containing a "bad"
combination of protocol parameter values so that dev-&gt;poll_mod_count
is not incremented inside pn533_poll_create_mod_list(), thus leading
to division by zero.
Call trace looks like:
nfc_genl_start_poll()
  nfc_start_poll()
    -&gt;start_poll()
    pn533_start_poll()

Add poll mod list filling check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-46676</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gtp: fix a potential NULL pointer dereference

When sockfd_lookup() fails, gtp_encap_enable_socket() returns a
NULL pointer, but its callers only check for error pointers thus miss
the NULL pointer case.

Fix it by returning an error pointer with the error code carried from
sockfd_lookup().

(I found this bug during code inspection.)</Note>
    </Notes>
    <CVE>CVE-2024-46677</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ethtool: check device is present when getting link settings

A sysfs reader can race with a device reset or removal, attempting to
read device state when the device is not actually present. eg:

     [exception RIP: qed_get_current_link+17]
  #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]
  #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3
 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4
 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300
 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c
 #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b
 #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3
 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1
 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f
 #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb

 crash&gt; struct net_device.state ffff9a9d21336000
    state = 5,

state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).
The device is not present, note lack of __LINK_STATE_PRESENT (0b10).

This is the same sort of panic as observed in commit 4224cfd7fb65
("net-sysfs: add check for netdevice being present to speed_show").

There are many other callers of __ethtool_get_link_ksettings() which
don't have a device presence check.

Move this check into ethtool to protect all callers.</Note>
    </Notes>
    <CVE>CVE-2024-46679</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pinctrl: single: fix potential NULL dereference in pcs_get_function()

pinmux_generic_get_function() can return NULL and the pointer 'function'
was dereferenced without checking against NULL. Add checking of pointer
'function' in pcs_get_function().

Found by code review.</Note>
    </Notes>
    <CVE>CVE-2024-46685</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req()

This happens when called from SMB2_read() while using rdma
and reaching the rdma_readwrite_threshold.</Note>
    </Notes>
    <CVE>CVE-2024-46686</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

thunderbolt: Mark XDomain as unplugged when router is removed

I noticed that when we do discrete host router NVM upgrade and it gets
hot-removed from the PCIe side as a result of NVM firmware authentication,
if there is another host connected with enabled paths we hang in tearing
them down. This is due to fact that the Thunderbolt networking driver
also tries to cleanup the paths and ends up blocking in
tb_disconnect_xdomain_paths() waiting for the domain lock.

However, at this point we already cleaned the paths in tb_stop() so
there is really no need for tb_disconnect_xdomain_paths() to do that
anymore. Furthermore it already checks if the XDomain is unplugged and
bails out early so take advantage of that and mark the XDomain as
unplugged when we remove the parent router.</Note>
    </Notes>
    <CVE>CVE-2024-46702</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3

On a system with a GICv3, if a guest hasn't been configured with
GICv3 and that the host is not capable of GICv2 emulation,
a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.

We therefore try to emulate the SGI access, only to hit a NULL
pointer as no private interrupt is allocated (no GIC, remember?).

The obvious fix is to give the guest what it deserves, in the
shape of a UNDEF exception.</Note>
    </Notes>
    <CVE>CVE-2024-46707</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

driver: iio: add missing checks on iio_info's callback access

Some callbacks from iio_info structure are accessed without any check, so
if a driver doesn't implement them trying to access the corresponding
sysfs entries produce a kernel oops such as:

[ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute
[...]
[ 2203.783416] Call trace:
[ 2203.783429]  iio_read_channel_info_avail from dev_attr_show+0x18/0x48
[ 2203.789807]  dev_attr_show from sysfs_kf_seq_show+0x90/0x120
[ 2203.794181]  sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4
[ 2203.798555]  seq_read_iter from vfs_read+0x238/0x2a0
[ 2203.802236]  vfs_read from ksys_read+0xa4/0xd4
[ 2203.805385]  ksys_read from ret_fast_syscall+0x0/0x54
[ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0)
[ 2203.812880] dfa0:                   00000003 b6f10f80 00000003 b6eab000 00020000 00000000
[ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000
[ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0
[ 2203.830363] Code: bad PC value
[ 2203.832695] ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2024-46715</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

apparmor: fix possible NULL pointer dereference

profile-&gt;parent-&gt;dents[AAFS_PROF_DIR] could be NULL only if its parent is made
from __create_missing_ancestors(..) and 'ent-&gt;old' is NULL in
aa_replace_profiles(..).
In that case, it must return an error code and the code, -ENOENT represents
its state that the path of its parent is not existed yet.

BUG: kernel NULL pointer dereference, address: 0000000000000030
PGD 0 P4D 0
PREEMPT SMP PTI
CPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
RIP: 0010:aafs_create.constprop.0+0x7f/0x130
Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc &lt;4d&gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae
RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0
Call Trace:
 &lt;TASK&gt;
 ? show_regs+0x6d/0x80
 ? __die+0x24/0x80
 ? page_fault_oops+0x99/0x1b0
 ? kernelmode_fixup_or_oops+0xb2/0x140
 ? __bad_area_nosemaphore+0x1a5/0x2c0
 ? find_vma+0x34/0x60
 ? bad_area_nosemaphore+0x16/0x30
 ? do_user_addr_fault+0x2a2/0x6b0
 ? exc_page_fault+0x83/0x1b0
 ? asm_exc_page_fault+0x27/0x30
 ? aafs_create.constprop.0+0x7f/0x130
 ? aafs_create.constprop.0+0x51/0x130
 __aafs_profile_mkdir+0x3d6/0x480
 aa_replace_profiles+0x83f/0x1270
 policy_update+0xe3/0x180
 profile_load+0xbc/0x150
 ? rw_verify_area+0x47/0x140
 vfs_write+0x100/0x480
 ? __x64_sys_openat+0x55/0xa0
 ? syscall_exit_to_user_mode+0x86/0x260
 ksys_write+0x73/0x100
 __x64_sys_write+0x19/0x30
 x64_sys_call+0x7e/0x25c0
 do_syscall_64+0x7f/0x180
 entry_SYSCALL_64_after_hwframe+0x78/0x80
RIP: 0033:0x7be9f211c574
Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89
RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574
RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004
RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80
R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30
 &lt;/TASK&gt;
Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas
CR2: 0000000000000030
---[ end trace 0000000000000000 ]---
RIP: 0010:aafs_create.constprop.0+0x7f/0x130
Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc &lt;4d&gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae
RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-46721</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 mc_data out-of-bounds read warning

Clear warning that read mc_data[i-1] may out-of-bounds.</Note>
    </Notes>
    <CVE>CVE-2024-46722</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 ucode out-of-bounds read warning

Clear warning that read ucode[] may out-of-bounds.</Note>
    </Notes>
    <CVE>CVE-2024-46723</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 out-of-bounds read of df_v1_7_channel_number

Check the fb_channel_number range to avoid the array out-of-bounds
read error</Note>
    </Notes>
    <CVE>CVE-2024-46724</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pm: fix the Out-of-bounds read warning

using index i - 1U may beyond element index
for mc_data[] when i = 0.</Note>
    </Notes>
    <CVE>CVE-2024-46731</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-tcp: fix kernel crash if commands allocation fails

If the commands allocation fails in nvmet_tcp_alloc_cmds()
the kernel crashes in nvmet_tcp_release_queue_work() because of
a NULL pointer dereference.

  nvmet: failed to install queue 0 cntlid 1 ret 6
  Unable to handle kernel NULL pointer dereference at
         virtual address 0000000000000008

Fix the bug by setting queue-&gt;nr_cmds to zero in case
nvmet_tcp_alloc_cmd() fails.</Note>
    </Notes>
    <CVE>CVE-2024-46737</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

VMCI: Fix use-after-free when removing resource in vmci_resource_remove()

When removing a resource from vmci_resource_table in
vmci_resource_remove(), the search is performed using the resource
handle by comparing context and resource fields.

It is possible though to create two resources with different types
but same handle (same context and resource fields).

When trying to remove one of the resources, vmci_resource_remove()
may not remove the intended one, but the object will still be freed
as in the case of the datagram type in vmci_datagram_destroy_handle().
vmci_resource_table will still hold a pointer to this freed resource
leading to a use-after-free vulnerability.

BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]
BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147
Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106
 print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239
 __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425
 kasan_report+0x38/0x51 mm/kasan/report.c:442
 vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]
 vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147
 vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182
 ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444
 kref_put include/linux/kref.h:65 [inline]
 vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]
 vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195
 vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143
 __fput+0x261/0xa34 fs/file_table.c:282
 task_work_run+0xf0/0x194 kernel/task_work.c:164
 tracehook_notify_resume include/linux/tracehook.h:189 [inline]
 exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187
 exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220
 __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]
 syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313
 do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86
 entry_SYSCALL_64_after_hwframe+0x6e/0x0

This change ensures the type is also checked when removing
the resource from vmci_resource_table in vmci_resource_remove().</Note>
    </Notes>
    <CVE>CVE-2024-46738</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

uio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind

For primary VM Bus channels, primary_channel pointer is always NULL. This
pointer is valid only for the secondary channels. Also, rescind callback
is meant for primary channels only.

Fix NULL pointer dereference by retrieving the device_obj from the parent
for the primary channel.</Note>
    </Notes>
    <CVE>CVE-2024-46739</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

of/irq: Prevent device address out-of-bounds read in interrupt map walk

When of_irq_parse_raw() is invoked with a device address smaller than
the interrupt parent node (from #address-cells property), KASAN detects
the following out-of-bounds read when populating the initial match table
(dyndbg="func of_irq_parse_* +p"):

  OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0
  OF:  parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2
  OF:  intspec=4
  OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2
  OF:  -&gt; addrsize=3
  ==================================================================
  BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0
  Read of size 4 at addr ffffff81beca5608 by task bash/764

  CPU: 1 PID: 764 Comm: bash Tainted: G           O       6.1.67-484c613561-nokia_sm_arm64 #1
  Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023
  Call trace:
   dump_backtrace+0xdc/0x130
   show_stack+0x1c/0x30
   dump_stack_lvl+0x6c/0x84
   print_report+0x150/0x448
   kasan_report+0x98/0x140
   __asan_load4+0x78/0xa0
   of_irq_parse_raw+0x2b8/0x8d0
   of_irq_parse_one+0x24c/0x270
   parse_interrupts+0xc0/0x120
   of_fwnode_add_links+0x100/0x2d0
   fw_devlink_parse_fwtree+0x64/0xc0
   device_add+0xb38/0xc30
   of_device_add+0x64/0x90
   of_platform_device_create_pdata+0xd0/0x170
   of_platform_bus_create+0x244/0x600
   of_platform_notify+0x1b0/0x254
   blocking_notifier_call_chain+0x9c/0xd0
   __of_changeset_entry_notify+0x1b8/0x230
   __of_changeset_apply_notify+0x54/0xe4
   of_overlay_fdt_apply+0xc04/0xd94
   ...

  The buggy address belongs to the object at ffffff81beca5600
   which belongs to the cache kmalloc-128 of size 128
  The buggy address is located 8 bytes inside of
   128-byte region [ffffff81beca5600, ffffff81beca5680)

  The buggy address belongs to the physical page:
  page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4
  head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0
  flags: 0x8000000000010200(slab|head|zone=2)
  raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300
  raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
  page dumped because: kasan: bad access detected

  Memory state around the buggy address:
   ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
   ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  &gt;ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                        ^
   ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
   ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc
  ==================================================================
  OF:  -&gt; got it !

Prevent the out-of-bounds read by copying the device address into a
buffer of sufficient size.</Note>
    </Notes>
    <CVE>CVE-2024-46743</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sanity check symbolic link size

Syzkiller reports a "KMSAN: uninit-value in pick_link" bug.

This is caused by an uninitialised page, which is ultimately caused
by a corrupted symbolic link size read from disk.

The reason why the corrupted symlink size causes an uninitialised
page is due to the following sequence of events:

1. squashfs_read_inode() is called to read the symbolic
   link from disk.  This assigns the corrupted value
   3875536935 to inode-&gt;i_size.

2. Later squashfs_symlink_read_folio() is called, which assigns
   this corrupted value to the length variable, which being a
   signed int, overflows producing a negative number.

3. The following loop that fills in the page contents checks that
   the copied bytes is less than length, which being negative means
   the loop is skipped, producing an uninitialised page.

This patch adds a sanity check which checks that the symbolic
link size is not larger than expected.

--

V2: fix spelling mistake.</Note>
    </Notes>
    <CVE>CVE-2024-46744</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Input: uinput - reject requests with unreasonable number of slots


When exercising uinput interface syzkaller may try setting up device
with a really large number of slots, which causes memory allocation
failure in input_mt_init_slots(). While this allocation failure is
handled properly and request is rejected, it results in syzkaller
reports. Additionally, such request may put undue burden on the
system which will try to free a lot of memory for a bogus request.

Fix it by limiting allowed number of slots to 100. This can easily
be extended if we see devices that can track more than 100 contacts.</Note>
    </Notes>
    <CVE>CVE-2024-46745</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

PCI: Add missing bridge lock to pci_bus_lock()

One of the true positives that the cfg_access_lock lockdep effort
identified is this sequence:

  WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70
  RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70
  Call Trace:
   &lt;TASK&gt;
   ? __warn+0x8c/0x190
   ? pci_bridge_secondary_bus_reset+0x5d/0x70
   ? report_bug+0x1f8/0x200
   ? handle_bug+0x3c/0x70
   ? exc_invalid_op+0x18/0x70
   ? asm_exc_invalid_op+0x1a/0x20
   ? pci_bridge_secondary_bus_reset+0x5d/0x70
   pci_reset_bus+0x1d8/0x270
   vmd_probe+0x778/0xa10
   pci_device_probe+0x95/0x120

Where pci_reset_bus() users are triggering unlocked secondary bus resets.
Ironically pci_bus_reset(), several calls down from pci_reset_bus(), uses
pci_bus_lock() before issuing the reset which locks everything *but* the
bridge itself.

For the same motivation as adding:

  bridge = pci_upstream_bridge(dev);
  if (bridge)
    pci_dev_lock(bridge);

to pci_reset_function() for the "bus" and "cxl_bus" reset cases, add
pci_dev_lock() for @bus-&gt;self to pci_bus_lock().

[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:
https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com]</Note>
    </Notes>
    <CVE>CVE-2024-46750</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: handle errors from btrfs_dec_ref() properly

In walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref().  This is
incorrect, we have proper error handling here, return the error.</Note>
    </Notes>
    <CVE>CVE-2024-46753</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()

mwifiex_get_priv_by_id() returns the priv pointer corresponding to
the bss_num and bss_type, but without checking if the priv is actually
currently in use.
Unused priv pointers do not have a wiphy attached to them which can
lead to NULL pointer dereferences further down the callstack.  Fix
this by returning only used priv pointers which have priv-&gt;bss_mode
set to something else than NL80211_IFTYPE_UNSPECIFIED.

Said NULL pointer dereference happened when an Accesspoint was started
with wpa_supplicant -i mlan0 with this config:

network={
        ssid="somessid"
        mode=2
        frequency=2412
        key_mgmt=WPA-PSK WPA-PSK-SHA256
        proto=RSN
        group=CCMP
        pairwise=CCMP
        psk="12345678"
}

When waiting for the AP to be established, interrupting wpa_supplicant
with &lt;ctrl-c&gt; and starting it again this happens:

| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140
| 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=0000000046d96000
| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000
| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio
+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs
+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6
| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18
| Hardware name: somemachine (DT)
| Workqueue: events sdio_irq_work
| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]
| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]
| sp : ffff8000818b3a70
| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004
| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9
| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000
| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000
| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517
| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1
| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157
| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124
| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000
| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000
| Call trace:
|  mwifiex_get_cfp+0xd8/0x15c [mwifiex]
|  mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]
|  mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]
|  mwifiex_process_sta_event+0x298/0xf0c [mwifiex]
|  mwifiex_process_event+0x110/0x238 [mwifiex]
|  mwifiex_main_process+0x428/0xa44 [mwifiex]
|  mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]
|  process_sdio_pending_irqs+0x64/0x1b8
|  sdio_irq_work+0x4c/0x7c
|  process_one_work+0x148/0x2a0
|  worker_thread+0x2fc/0x40c
|  kthread+0x110/0x114
|  ret_from_fork+0x10/0x20
| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)
| ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2024-46755</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: (adc128d818) Fix underflows seen when writing limit attributes

DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large
negative number such as -9223372036854775808 is provided by the user.
Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.</Note>
    </Notes>
    <CVE>CVE-2024-46759</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv

The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel
crash when we try to hot-unplug/disable the PCIe switch/bridge from
the PHB.

The crash occurs because although the MSI data structure has been
released during disable/hot-unplug path and it has been assigned
with NULL, still during unregistration the code was again trying to
explicitly disable the MSI which causes the NULL pointer dereference and
kernel crash.

The patch fixes the check during unregistration path to prevent invoking
pci_disable_msi/msix() since its data structure is already freed.</Note>
    </Notes>
    <CVE>CVE-2024-46761</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Add netif_device_attach/detach into PF reset flow

Ethtool callbacks can be executed while reset is in progress and try to
access deleted resources, e.g. getting coalesce settings can result in a
NULL pointer dereference seen below.

Reproduction steps:
Once the driver is fully initialized, trigger reset:
	# echo 1 &gt; /sys/class/net/&lt;interface&gt;/device/reset
when reset is in progress try to get coalesce settings using ethtool:
	# ethtool -c &lt;interface&gt;

BUG: kernel NULL pointer dereference, address: 0000000000000020
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 11 PID: 19713 Comm: ethtool Tainted: G S                 6.10.0-rc7+ #7
RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]
RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206
RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000
R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40
FS:  00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0
Call Trace:
&lt;TASK&gt;
ice_get_coalesce+0x17/0x30 [ice]
coalesce_prepare_data+0x61/0x80
ethnl_default_doit+0xde/0x340
genl_family_rcv_msg_doit+0xf2/0x150
genl_rcv_msg+0x1b3/0x2c0
netlink_rcv_skb+0x5b/0x110
genl_rcv+0x28/0x40
netlink_unicast+0x19c/0x290
netlink_sendmsg+0x222/0x490
__sys_sendto+0x1df/0x1f0
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x82/0x160
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7faee60d8e27

Calling netif_device_detach() before reset makes the net core not call
the driver when ethtool command is issued, the attempt to execute an
ethtool command during reset will result in the following message:

    netlink error: No such device

instead of NULL pointer dereference. Once reset is done and
ice_rebuild() is executing, the netif_device_attach() is called to allow
for ethtool operations to occur again in a safe manner.</Note>
    </Notes>
    <CVE>CVE-2024-46770</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

can: bcm: Remove proc entry when dev is unregistered.

syzkaller reported a warning in bcm_connect() below. [0]

The repro calls connect() to vxcan1, removes vxcan1, and calls
connect() with ifindex == 0.

Calling connect() for a BCM socket allocates a proc entry.
Then, bcm_sk(sk)-&gt;bound is set to 1 to prevent further connect().

However, removing the bound device resets bcm_sk(sk)-&gt;bound to 0
in bcm_notify().

The 2nd connect() tries to allocate a proc entry with the same
name and sets NULL to bcm_sk(sk)-&gt;bcm_proc_read, leaking the
original proc entry.

Since the proc entry is available only for connect()ed sockets,
let's clean up the entry when the bound netdev is unregistered.

[0]:
proc_dir_entry 'can-bcm/2456' already registered
WARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375
Modules linked in:
CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375
Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 &lt;0f&gt; 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48
RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246
RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002
RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0
R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec
FS:  00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220
 bcm_connect+0x472/0x840 net/can/bcm.c:1673
 __sys_connect_file net/socket.c:2049 [inline]
 __sys_connect+0x5d2/0x690 net/socket.c:2066
 __do_sys_connect net/socket.c:2076 [inline]
 __se_sys_connect net/socket.c:2073 [inline]
 __x64_sys_connect+0x8f/0x100 net/socket.c:2073
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7fbd708b0e5d
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48
RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d
RDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040
R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098
R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000
 &lt;/TASK&gt;
remove_proc_entry: removing non-empty directory 'net/can-bcm', leaking at least '2456'</Note>
    </Notes>
    <CVE>CVE-2024-46771</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

powerpc/rtas: Prevent Spectre v1 gadget construction in sys_rtas()

Smatch warns:

  arch/powerpc/kernel/rtas.c:1932 __do_sys_rtas() warn: potential
  spectre issue 'args.args' [r] (local cap)

The 'nargs' and 'nret' locals come directly from a user-supplied
buffer and are used as indexes into a small stack-based array and as
inputs to copy_to_user() after they are subject to bounds checks.

Use array_index_nospec() after the bounds checks to clamp these values
for speculative execution.</Note>
    </Notes>
    <CVE>CVE-2024-46774</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

udf: Avoid excessive partition lengths

Avoid mounting filesystems where the partition would overflow the
32-bits used for block number. Also refuse to mount filesystems where
the partition length is so large we cannot safely index bits in a
block bitmap.</Note>
    </Notes>
    <CVE>CVE-2024-46777</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tcp_bpf: fix return value of tcp_bpf_sendmsg()

When we cork messages in psock-&gt;cork, the last message triggers the
flushing will result in sending a sk_msg larger than the current
message size. In this case, in tcp_bpf_send_verdict(), 'copied' becomes
negative at least in the following case:

468         case __SK_DROP:
469         default:
470                 sk_msg_free_partial(sk, msg, tosend);
471                 sk_msg_apply_bytes(psock, tosend);
472                 *copied -= (tosend + delta); // &lt;==== HERE
473                 return -EACCES;

Therefore, it could lead to the following BUG with a proper value of
'copied' (thanks to syzbot). We should not use negative 'copied' as a
return value here.

  ------------[ cut here ]------------
  kernel BUG at net/socket.c:733!
  Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
  Modules linked in:
  CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0
  Hardware name: linux,dummy-virt (DT)
  pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
  pc : sock_sendmsg_nosec net/socket.c:733 [inline]
  pc : sock_sendmsg_nosec net/socket.c:728 [inline]
  pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745
  lr : sock_sendmsg_nosec net/socket.c:730 [inline]
  lr : __sock_sendmsg+0x54/0x60 net/socket.c:745
  sp : ffff800088ea3b30
  x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000
  x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000
  x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90
  x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001
  x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf
  x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
  x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0
  x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000
  x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900
  x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef
  Call trace:
   sock_sendmsg_nosec net/socket.c:733 [inline]
   __sock_sendmsg+0x5c/0x60 net/socket.c:745
   ____sys_sendmsg+0x274/0x2ac net/socket.c:2597
   ___sys_sendmsg+0xac/0x100 net/socket.c:2651
   __sys_sendmsg+0x84/0xe0 net/socket.c:2680
   __do_sys_sendmsg net/socket.c:2689 [inline]
   __se_sys_sendmsg net/socket.c:2687 [inline]
   __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687
   __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
   invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49
   el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132
   do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151
   el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712
   el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730
   el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598
  Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000)
  ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2024-46783</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: mana: Fix error handling in mana_create_txq/rxq's NAPI cleanup

Currently napi_disable() gets called during rxq and txq cleanup,
even before napi is enabled and hrtimer is initialized. It causes
kernel panic.

? page_fault_oops+0x136/0x2b0
  ? page_counter_cancel+0x2e/0x80
  ? do_user_addr_fault+0x2f2/0x640
  ? refill_obj_stock+0xc4/0x110
  ? exc_page_fault+0x71/0x160
  ? asm_exc_page_fault+0x27/0x30
  ? __mmdrop+0x10/0x180
  ? __mmdrop+0xec/0x180
  ? hrtimer_active+0xd/0x50
  hrtimer_try_to_cancel+0x2c/0xf0
  hrtimer_cancel+0x15/0x30
  napi_disable+0x65/0x90
  mana_destroy_rxq+0x4c/0x2f0
  mana_create_rxq.isra.0+0x56c/0x6d0
  ? mana_uncfg_vport+0x50/0x50
  mana_alloc_queues+0x21b/0x320
  ? skb_dequeue+0x5f/0x80</Note>
    </Notes>
    <CVE>CVE-2024-46784</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

userfaultfd: fix checks for huge PMDs

Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2.

The pmd_trans_huge() code in mfill_atomic() is wrong in three different
ways depending on kernel version:

1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit
   the right two race windows) - I've tested this in a kernel build with
   some extra mdelay() calls. See the commit message for a description
   of the race scenario.
   On older kernels (before 6.5), I think the same bug can even
   theoretically lead to accessing transhuge page contents as a page table
   if you hit the right 5 narrow race windows (I haven't tested this case).
2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for
   detecting PMDs that don't point to page tables.
   On older kernels (before 6.5), you'd just have to win a single fairly
   wide race to hit this.
   I've tested this on 6.1 stable by racing migration (with a mdelay()
   patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86
   VM, that causes a kernel oops in ptlock_ptr().
3. On newer kernels (&gt;=6.5), for shmem mappings, khugepaged is allowed
   to yank page tables out from under us (though I haven't tested that),
   so I think the BUG_ON() checks in mfill_atomic() are just wrong.

I decided to write two separate fixes for these (one fix for bugs 1+2, one
fix for bug 3), so that the first fix can be backported to kernels
affected by bugs 1+2.


This patch (of 2):

This fixes two issues.

I discovered that the following race can occur:

  mfill_atomic                other thread
  ============                ============
                              &lt;zap PMD&gt;
  pmdp_get_lockless() [reads none pmd]
  &lt;bail if trans_huge&gt;
  &lt;if none:&gt;
                              &lt;pagefault creates transhuge zeropage&gt;
    __pte_alloc [no-op]
                              &lt;zap PMD&gt;
  &lt;bail if pmd_trans_huge(*dst_pmd)&gt;
  BUG_ON(pmd_none(*dst_pmd))

I have experimentally verified this in a kernel with extra mdelay() calls;
the BUG_ON(pmd_none(*dst_pmd)) triggers.

On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow
pte_offset_map[_lock]() to fail"), this can't lead to anything worse than
a BUG_ON(), since the page table access helpers are actually designed to
deal with page tables concurrently disappearing; but on older kernels
(&lt;=6.4), I think we could probably theoretically race past the two
BUG_ON() checks and end up treating a hugepage as a page table.

The second issue is that, as Qi Zheng pointed out, there are other types
of huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs
(in particular, migration PMDs).

On &lt;=6.4, this is worse than the first issue: If mfill_atomic() runs on a
PMD that contains a migration entry (which just requires winning a single,
fairly wide race), it will pass the PMD to pte_offset_map_lock(), which
assumes that the PMD points to a page table.

Breakage follows: First, the kernel tries to take the PTE lock (which will
crash or maybe worse if there is no "struct page" for the address bits in
the migration entry PMD - I think at least on X86 there usually is no
corresponding "struct page" thanks to the PTE inversion mitigation, amd64
looks different).

If that didn't crash, the kernel would next try to write a PTE into what
it wrongly thinks is a page table.

As part of fixing these issues, get rid of the check for pmd_trans_huge()
before __pte_alloc() - that's redundant, we're going to have to check for
that after the __pte_alloc() anyway.

Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.</Note>
    </Notes>
    <CVE>CVE-2024-46787</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sch/netem: fix use after free in netem_dequeue

If netem_dequeue() enqueues packet to inner qdisc and that qdisc
returns __NET_XMIT_STOLEN. The packet is dropped but
qdisc_tree_reduce_backlog() is not called to update the parent's
q.qlen, leading to the similar use-after-free as Commit
e04991a48dbaf382 ("netem: fix return value if duplicate enqueue
fails")

Commands to trigger KASAN UaF:

ip link add type dummy
ip link set lo up
ip link set dummy0 up
tc qdisc add dev lo parent root handle 1: drr
tc filter add dev lo parent 1: basic classid 1:1
tc class add dev lo classid 1:1 drr
tc qdisc add dev lo parent 1:1 handle 2: netem
tc qdisc add dev lo parent 2: handle 3: drr
tc filter add dev lo parent 3: basic classid 3:1 action mirred egress
redirect dev dummy0
tc class add dev lo classid 3:1 drr
ping -c1 -W0.01 localhost # Trigger bug
tc class del dev lo classid 1:1
tc class add dev lo classid 1:1 drr
ping -c1 -W0.01 localhost # UaF</Note>
    </Notes>
    <CVE>CVE-2024-46800</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: added NULL check at start of dc_validate_stream

[Why]
prevent invalid memory access

[How]
check if dc and stream are NULL</Note>
    </Notes>
    <CVE>CVE-2024-46802</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check BIOS images before it is used

BIOS images may fail to load and null checks are added before they are
used.

This fixes 6 NULL_RETURNS issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-46809</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check link_index before accessing dc-&gt;links[]

[WHY &amp; HOW]
dc-&gt;links[] has max size of MAX_LINKS and NULL is return when trying to
access with out-of-bound index.

This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-46813</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links

[Why]
Coverity report OVERRUN warning. There are
only max_links elements within dc-&gt;links. link
count could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31.

[How]
Make sure link count less than max_links.</Note>
    </Notes>
    <CVE>CVE-2024-46816</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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/amd/display: Check gpio_id before used as array index

[WHY &amp; HOW]
GPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore
should be checked in advance.

This fixes 5 OVERRUN issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-46818</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry

In a review discussion of the changes to support vCPU hotplug where
a check was added on the GICC being enabled if was online, it was
noted that there is need to map back to the cpu and use that to index
into a cpumask. As such, a valid ID is needed.

If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possible
for the entry in cpu_madt_gicc[cpu] == NULL.  This function would
then cause a NULL pointer dereference.   Whilst a path to trigger
this has not been established, harden this caller against the
possibility.</Note>
    </Notes>
    <CVE>CVE-2024-46822</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ELF: fix kernel.randomize_va_space double read

ELF loader uses "randomize_va_space" twice. It is sysctl and can change
at any moment, so 2 loads could see 2 different values in theory with
unpredictable consequences.

Issue exactly one load for consistent value across one exec.</Note>
    </Notes>
    <CVE>CVE-2024-46826</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ethtool: fail closed if we can't get max channel used in indirection tables

Commit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with
active RSS contexts") proves that allowing indirection table to contain
channels with out of bounds IDs may lead to crashes. Currently the
max channel check in the core gets skipped if driver can't fetch
the indirection table or when we can't allocate memory.

Both of those conditions should be extremely rare but if they do
happen we should try to be safe and fail the channel change.</Note>
    </Notes>
    <CVE>CVE-2024-46834</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: clean up our handling of refs == 0 in snapshot delete

In reada we BUG_ON(refs == 0), which could be unkind since we aren't
holding a lock on the extent leaf and thus could get a transient
incorrect answer.  In walk_down_proc we also BUG_ON(refs == 0), which
could happen if we have extent tree corruption.  Change that to return
-EUCLEAN.  In do_walk_down() we catch this case and handle it correctly,
however we return -EIO, which -EUCLEAN is a more appropriate error code.
Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert
that to proper error handling.  Also adjust the error message so we can
actually do something with the information.</Note>
    </Notes>
    <CVE>CVE-2024-46840</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()

We handle errors here properly, ENOMEM isn't fatal, return the error.</Note>
    </Notes>
    <CVE>CVE-2024-46841</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel: Limit the period on Haswell

Running the ltp test cve-2015-3290 concurrently reports the following
warnings.

perfevents: irq loop stuck!
  WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174
  intel_pmu_handle_irq+0x285/0x370
  Call Trace:
   &lt;NMI&gt;
   ? __warn+0xa4/0x220
   ? intel_pmu_handle_irq+0x285/0x370
   ? __report_bug+0x123/0x130
   ? intel_pmu_handle_irq+0x285/0x370
   ? __report_bug+0x123/0x130
   ? intel_pmu_handle_irq+0x285/0x370
   ? report_bug+0x3e/0xa0
   ? handle_bug+0x3c/0x70
   ? exc_invalid_op+0x18/0x50
   ? asm_exc_invalid_op+0x1a/0x20
   ? irq_work_claim+0x1e/0x40
   ? intel_pmu_handle_irq+0x285/0x370
   perf_event_nmi_handler+0x3d/0x60
   nmi_handle+0x104/0x330

Thanks to Thomas Gleixner's analysis, the issue is caused by the low
initial period (1) of the frequency estimation algorithm, which triggers
the defects of the HW, specifically erratum HSW11 and HSW143. (For the
details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)

The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL
event, but the initial period in the freq mode is 1. The erratum is the
same as the BDM11, which has been supported in the kernel. A minimum
period of 128 is enforced as well on HSW.

HSW143 is regarding that the fixed counter 1 may overcount 32 with the
Hyper-Threading is enabled. However, based on the test, the hardware
has more issues than it tells. Besides the fixed counter 1, the message
'interrupt took too long' can be observed on any counter which was armed
with a period &lt; 32 and two events expired in the same NMI. A minimum
period of 32 is enforced for the rest of the events.
The recommended workaround code of the HSW143 is not implemented.
Because it only addresses the issue for the fixed counter. It brings
extra overhead through extra MSR writing. No related overcounting issue
has been reported so far.</Note>
    </Notes>
    <CVE>CVE-2024-46848</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: nxp-fspi: fix the KASAN report out-of-bounds bug

Change the memcpy length to fix the out-of-bounds issue when writing the
data that is not 4 byte aligned to TX FIFO.

To reproduce the issue, write 3 bytes data to NOR chip.

dd if=3b of=/dev/mtd0
[   36.926103] ==================================================================
[   36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838
[   36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455
[   36.946721]
[   36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070
[   36.956185] Hardware name: Freescale i.MX8QM MEK (DT)
[   36.961260] Call trace:
[   36.963723]  dump_backtrace+0x90/0xe8
[   36.967414]  show_stack+0x18/0x24
[   36.970749]  dump_stack_lvl+0x78/0x90
[   36.974451]  print_report+0x114/0x5cc
[   36.978151]  kasan_report+0xa4/0xf0
[   36.981670]  __asan_report_load_n_noabort+0x1c/0x28
[   36.986587]  nxp_fspi_exec_op+0x26ec/0x2838
[   36.990800]  spi_mem_exec_op+0x8ec/0xd30
[   36.994762]  spi_mem_no_dirmap_read+0x190/0x1e0
[   36.999323]  spi_mem_dirmap_write+0x238/0x32c
[   37.003710]  spi_nor_write_data+0x220/0x374
[   37.007932]  spi_nor_write+0x110/0x2e8
[   37.011711]  mtd_write_oob_std+0x154/0x1f0
[   37.015838]  mtd_write_oob+0x104/0x1d0
[   37.019617]  mtd_write+0xb8/0x12c
[   37.022953]  mtdchar_write+0x224/0x47c
[   37.026732]  vfs_write+0x1e4/0x8c8
[   37.030163]  ksys_write+0xec/0x1d0
[   37.033586]  __arm64_sys_write+0x6c/0x9c
[   37.037539]  invoke_syscall+0x6c/0x258
[   37.041327]  el0_svc_common.constprop.0+0x160/0x22c
[   37.046244]  do_el0_svc+0x44/0x5c
[   37.049589]  el0_svc+0x38/0x78
[   37.052681]  el0t_64_sync_handler+0x13c/0x158
[   37.057077]  el0t_64_sync+0x190/0x194
[   37.060775]
[   37.062274] Allocated by task 455:
[   37.065701]  kasan_save_stack+0x2c/0x54
[   37.069570]  kasan_save_track+0x20/0x3c
[   37.073438]  kasan_save_alloc_info+0x40/0x54
[   37.077736]  __kasan_kmalloc+0xa0/0xb8
[   37.081515]  __kmalloc_noprof+0x158/0x2f8
[   37.085563]  mtd_kmalloc_up_to+0x120/0x154
[   37.089690]  mtdchar_write+0x130/0x47c
[   37.093469]  vfs_write+0x1e4/0x8c8
[   37.096901]  ksys_write+0xec/0x1d0
[   37.100332]  __arm64_sys_write+0x6c/0x9c
[   37.104287]  invoke_syscall+0x6c/0x258
[   37.108064]  el0_svc_common.constprop.0+0x160/0x22c
[   37.112972]  do_el0_svc+0x44/0x5c
[   37.116319]  el0_svc+0x38/0x78
[   37.119401]  el0t_64_sync_handler+0x13c/0x158
[   37.123788]  el0t_64_sync+0x190/0x194
[   37.127474]
[   37.128977] The buggy address belongs to the object at ffff00081037c2a0
[   37.128977]  which belongs to the cache kmalloc-8 of size 8
[   37.141177] The buggy address is located 0 bytes inside of
[   37.141177]  allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)
[   37.153465]
[   37.154971] The buggy address belongs to the physical page:
[   37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c
[   37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)
[   37.175149] page_type: 0xfdffffff(slab)
[   37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000
[   37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000
[   37.194553] page dumped because: kasan: bad access detected
[   37.200144]
[   37.201647] Memory state around the buggy address:
[   37.206460]  ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc
[   37.213701]  ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc
[   37.220946] &gt;ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc
[   37.228186]                                ^
[   37.232473]  ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   37.239718]  ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   37.246962] ==============================================================
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-46853</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dpaa: Pad packets to ETH_ZLEN

When sending packets under 60 bytes, up to three bytes of the buffer
following the data may be leaked. Avoid this by extending all packets to
ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be
reproduced by running

	$ ping -s 11 destination</Note>
    </Notes>
    <CVE>CVE-2024-46854</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: panasonic-laptop: Fix SINF array out of bounds accesses

The panasonic laptop code in various places uses the SINF array with index
values of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF array
is big enough.

Not all panasonic laptops have this many SINF array entries, for example
the Toughbook CF-18 model only has 10 SINF array entries. So it only
supports the AC+DC brightness entries and mute.

Check that the SINF array has a minimum size which covers all AC+DC
brightness entries and refuse to load if the SINF array is smaller.

For higher SINF indexes hide the sysfs attributes when the SINF array
does not contain an entry for that attribute, avoiding show()/store()
accessing the array out of bounds and add bounds checking to the probe()
and resume() code accessing these.</Note>
    </Notes>
    <CVE>CVE-2024-46859</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** DISPUTED ** An issue was discovered in the WEBrick toolkit through 1.8.1 for Ruby. It allows HTTP request smuggling by providing both a Content-Length header and a Transfer-Encoding header, e.g., "GET /admin HTTP/1.1\r\n" inside of a "POST /user HTTP/1.1\r\n" request. NOTE: the supplier's position is "Webrick should not be used in production."</Note>
    </Notes>
    <CVE>CVE-2024-47220</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libruby2_1-2_1-2.1.9-19.9.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:ruby2.1-2.1.9-19.9.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:ruby2.1-stdlib-2.1.9-19.9.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fsnotify: clear PARENT_WATCHED flags lazily

In some setups directories can have many (usually negative) dentries.
Hence __fsnotify_update_child_dentry_flags() function can take a
significant amount of time. Since the bulk of this function happens
under inode-&gt;i_lock this causes a significant contention on the lock
when we remove the watch from the directory as the
__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()
races with __fsnotify_update_child_dentry_flags() calls from
__fsnotify_parent() happening on children. This can lead upto softlockup
reports reported by users.

Fix the problem by calling fsnotify_update_children_dentry_flags() to
set PARENT_WATCHED flags only when parent starts watching children.

When parent stops watching children, clear false positive PARENT_WATCHED
flags lazily in __fsnotify_parent() for each accessed child.</Note>
    </Notes>
    <CVE>CVE-2024-47660</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead

There is a WARNING in iwl_trans_wait_tx_queues_empty() (that was
recently converted from just a message), that can be hit if we
wait for TX queues to become empty after firmware died. Clearly,
we can't expect anything from the firmware after it's declared dead.

Don't call iwl_trans_wait_tx_queues_empty() in this case. While it could
be a good idea to stop the flow earlier, the flush functions do some
maintenance work that is not related to the firmware, so keep that part
of the code running even when the firmware is not running.

[edit commit message]</Note>
    </Notes>
    <CVE>CVE-2024-47672</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: pause TCM when the firmware is stopped

Not doing so will make us send a host command to the transport while the
firmware is not alive, which will trigger a WARNING.

bad state = 0
WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]
RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]
Call Trace:
 &lt;TASK&gt;
 iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm]
 iwl_mvm_config_scan+0x198/0x260 [iwlmvm]
 iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm]
 iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm]
 process_one_work+0x29e/0x640
 worker_thread+0x2df/0x690
 ? rescuer_thread+0x540/0x540
 kthread+0x192/0x1e0
 ? set_kthread_struct+0x90/0x90
 ret_from_fork+0x22/0x30</Note>
    </Notes>
    <CVE>CVE-2024-47673</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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: avoid leaving partial pfn mappings around in error case

As Jann points out, PFN mappings are special, because unlike normal
memory mappings, there is no lifetime information associated with the
mapping - it is just a raw mapping of PFNs with no reference counting of
a 'struct page'.

That's all very much intentional, but it does mean that it's easy to
mess up the cleanup in case of errors.  Yes, a failed mmap() will always
eventually clean up any partial mappings, but without any explicit
lifetime in the page table mapping itself, it's very easy to do the
error handling in the wrong order.

In particular, it's easy to mistakenly free the physical backing store
before the page tables are actually cleaned up and (temporarily) have
stale dangling PTE entries.

To make this situation less error-prone, just make sure that any partial
pfn mapping is torn down early, before any other error handling.</Note>
    </Notes>
    <CVE>CVE-2024-47674</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

vfs: fix race between evice_inodes() and find_inode()&amp;iput()

Hi, all

Recently I noticed a bug[1] in btrfs, after digged it into
and I believe it'a race in vfs.

Let's assume there's a inode (ie ino 261) with i_count 1 is
called by iput(), and there's a concurrent thread calling
generic_shutdown_super().

cpu0:                              cpu1:
iput() // i_count is 1
  -&gt;spin_lock(inode)
  -&gt;dec i_count to 0
  -&gt;iput_final()                    generic_shutdown_super()
    -&gt;__inode_add_lru()               -&gt;evict_inodes()
      // cause some reason[2]           -&gt;if (atomic_read(inode-&gt;i_count)) continue;
      // return before                  // inode 261 passed the above check
      // list_lru_add_obj()             // and then schedule out
   -&gt;spin_unlock()
// note here: the inode 261
// was still at sb list and hash list,
// and I_FREEING|I_WILL_FREE was not been set

btrfs_iget()
  // after some function calls
  -&gt;find_inode()
    // found the above inode 261
    -&gt;spin_lock(inode)
   // check I_FREEING|I_WILL_FREE
   // and passed
      -&gt;__iget()
    -&gt;spin_unlock(inode)                // schedule back
                                        -&gt;spin_lock(inode)
                                        // check (I_NEW|I_FREEING|I_WILL_FREE) flags,
                                        // passed and set I_FREEING
iput()                                  -&gt;spin_unlock(inode)
  -&gt;spin_lock(inode)			  -&gt;evict()
  // dec i_count to 0
  -&gt;iput_final()
    -&gt;spin_unlock()
    -&gt;evict()

Now, we have two threads simultaneously evicting
the same inode, which may trigger the BUG(inode-&gt;i_state &amp; I_CLEAR)
statement both within clear_inode() and iput().

To fix the bug, recheck the inode-&gt;i_count after holding i_lock.
Because in the most scenarios, the first check is valid, and
the overhead of spin_lock() can be reduced.

If there is any misunderstanding, please let me know, thanks.

[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/
[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()
return false when I reproduced the bug.</Note>
    </Notes>
    <CVE>CVE-2024-47679</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tcp: check skb is non-NULL in tcp_rto_delta_us()

We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic
kernel that are running ceph and recently hit a null ptr dereference in
tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also
saw it getting hit from the RACK case as well. Here are examples of the oops
messages we saw in each of those cases:

Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020
Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode
Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page
Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0
Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI
Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu
Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023
Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160
Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 &lt;48&gt; 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3
Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246
Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000
Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60
Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8
Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900
Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30
Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000
Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0
Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554
Jul 26 15:05:02 rx [11061395.916786] Call Trace:
Jul 26 15:05:02 rx [11061395.919488]
Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f
Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9
Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380
Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0
Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50
Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0
Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20
Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450
Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140
Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90
Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0
Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40
Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160
Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160
Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220
Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240
Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0
Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240
Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130
Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280
Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10
Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30
Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-47684</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()

syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending
garbage on the four reserved tcp bits (th-&gt;res1)

Use skb_put_zero() to clear the whole TCP header,
as done in nf_reject_ip_tcphdr_put()

BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255
  nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255
  nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344
  nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
  nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
  nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
  nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
  nf_hook include/linux/netfilter.h:269 [inline]
  NF_HOOK include/linux/netfilter.h:312 [inline]
  ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
  __netif_receive_skb_one_core net/core/dev.c:5661 [inline]
  __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775
  process_backlog+0x4ad/0xa50 net/core/dev.c:6108
  __napi_poll+0xe7/0x980 net/core/dev.c:6772
  napi_poll net/core/dev.c:6841 [inline]
  net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963
  handle_softirqs+0x1ce/0x800 kernel/softirq.c:554
  __do_softirq+0x14/0x1a kernel/softirq.c:588
  do_softirq+0x9a/0x100 kernel/softirq.c:455
  __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382
  local_bh_enable include/linux/bottom_half.h:33 [inline]
  rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline]
  __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450
  dev_queue_xmit include/linux/netdevice.h:3105 [inline]
  neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565
  neigh_output include/net/neighbour.h:542 [inline]
  ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141
  __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]
  ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226
  NF_HOOK_COND include/linux/netfilter.h:303 [inline]
  ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247
  dst_output include/net/dst.h:450 [inline]
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366
  inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135
  __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466
  tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]
  tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143
  tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333
  __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679
  inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750
  __sys_connect_file net/socket.c:2061 [inline]
  __sys_connect+0x606/0x690 net/socket.c:2078
  __do_sys_connect net/socket.c:2088 [inline]
  __se_sys_connect net/socket.c:2085 [inline]
  __x64_sys_connect+0x91/0xe0 net/socket.c:2085
  x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was stored to memory at:
  nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249
  nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344
  nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48
  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
  nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288
  nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161
  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
  nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
  nf_hook include/linux/netfilter.h:269 [inline]
  NF_HOOK include/linux/netfilter.h:312 [inline]
  ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310
  __netif_receive_skb_one_core
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-47685</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency

In the commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to
destroying CM IDs"), the function flush_workqueue is invoked to flush the
work queue iwcm_wq.

But at that time, the work queue iwcm_wq was created via the function
alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.

Because the current process is trying to flush the whole iwcm_wq, if
iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current
process is not reclaiming memory or running on a workqueue which doesn't
have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee
leading to a deadlock.

The call trace is as below:

[  125.350876][ T1430] Call Trace:
[  125.356281][ T1430]  &lt;TASK&gt;
[ 125.361285][ T1430] ? __warn (kernel/panic.c:693)
[ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
[ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219)
[ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239)
[ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))
[ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)
[ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
[ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))
[ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970)
[ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151)
[ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm
[ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910)
[ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)
[ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161)
[ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm
[ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma
[ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma
[ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231)
[ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393)
[ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339)
[ 125.531837][ T1430] kthread (kernel/kthread.c:389)
[ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342)
[ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147)
[ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342)
[ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257)
[  125.566487][ T1430]  &lt;/TASK&gt;
[  125.566488][ T1430] ---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2024-47696</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error

Ensure index in rtl2830_pid_filter does not exceed 31 to prevent
out-of-bounds access.

dev-&gt;filters is a 32-bit value, so set_bit and clear_bit functions should
only operate on indices from 0 to 31. If index is 32, it will attempt to
access a non-existent 33rd bit, leading to out-of-bounds access.
Change the boundary check from index &gt; 32 to index &gt;= 32 to resolve this
issue.</Note>
    </Notes>
    <CVE>CVE-2024-47697</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error

Ensure index in rtl2832_pid_filter does not exceed 31 to prevent
out-of-bounds access.

dev-&gt;filters is a 32-bit value, so set_bit and clear_bit functions should
only operate on indices from 0 to 31. If index is 32, it will attempt to
access a non-existent 33rd bit, leading to out-of-bounds access.
Change the boundary check from index &gt; 32 to index &gt;= 32 to resolve this
issue.

[hverkuil: added fixes tag, rtl2830_pid_filter -&gt; rtl2832_pid_filter in logmsg]</Note>
    </Notes>
    <CVE>CVE-2024-47698</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: avoid OOB when system.data xattr changes underneath the filesystem

When looking up for an entry in an inlined directory, if e_value_offs is
changed underneath the filesystem by some change in the block device, it
will lead to an out-of-bounds access that KASAN detects as an UAF.

EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.
loop0: detected capacity change from 2048 to 2047
==================================================================
BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500
Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103

CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:93 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:488
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500
 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697
 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573
 ext4_lookup_entry fs/ext4/namei.c:1727 [inline]
 ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795
 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633
 filename_create+0x297/0x540 fs/namei.c:3980
 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587
 __do_sys_symlinkat fs/namei.c:4610 [inline]
 __se_sys_symlinkat fs/namei.c:4607 [inline]
 __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f3e73ced469
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a
RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469
RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0
RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290
R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c
R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0
 &lt;/TASK&gt;

Calling ext4_xattr_ibody_find right after reading the inode with
ext4_get_inode_loc will lead to a check of the validity of the xattrs,
avoiding this problem.</Note>
    </Notes>
    <CVE>CVE-2024-47701</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

block, bfq: fix possible UAF for bfqq-&gt;bic with merge chain

1) initial state, three tasks:

		Process 1       Process 2	Process 3
		 (BIC1)          (BIC2)		 (BIC3)
		  |  Λ            |  Λ		  |  Λ
		  |  |            |  |		  |  |
		  V  |            V  |		  V  |
		  bfqq1           bfqq2		  bfqq3
process ref:	   1		    1		    1

2) bfqq1 merged to bfqq2:

		Process 1       Process 2	Process 3
		 (BIC1)          (BIC2)		 (BIC3)
		  |               |		  |  Λ
		  \--------------\|		  |  |
		                  V		  V  |
		  bfqq1---------&gt;bfqq2		  bfqq3
process ref:	   0		    2		    1

3) bfqq2 merged to bfqq3:

		Process 1       Process 2	Process 3
		 (BIC1)          (BIC2)		 (BIC3)
	 here -&gt; Λ                |		  |
		  \--------------\ \-------------\|
		                  V		  V
		  bfqq1---------&gt;bfqq2----------&gt;bfqq3
process ref:	   0		    1		    3

In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then
get bfqq3 through merge chain, and finially handle IO by bfqq3.
Howerver, current code will think bfqq2 is owned by BIC1, like initial
state, and set bfqq2-&gt;bic to BIC1.

bfq_insert_request
-&gt; by Process 1
 bfqq = bfq_init_rq(rq)
  bfqq = bfq_get_bfqq_handle_split
   bfqq = bic_to_bfqq
   -&gt; get bfqq2 from BIC1
 bfqq-&gt;ref++
 rq-&gt;elv.priv[0] = bic
 rq-&gt;elv.priv[1] = bfqq
 if (bfqq_process_refs(bfqq) == 1)
  bfqq-&gt;bic = bic
  -&gt; record BIC1 to bfqq2

  __bfq_insert_request
   new_bfqq = bfq_setup_cooperator
   -&gt; get bfqq3 from bfqq2-&gt;new_bfqq
   bfqq_request_freed(bfqq)
   new_bfqq-&gt;ref++
   rq-&gt;elv.priv[1] = new_bfqq
   -&gt; handle IO by bfqq3

Fix the problem by checking bfqq is from merge chain fist. And this
might fix a following problem reported by our syzkaller(unreproducible):

==================================================================
BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]
BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]
BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889
Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595

CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G             L     6.6.0-07439-gba2303cacfda #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Workqueue: kblockd blk_mq_requeue_work
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:364 [inline]
 print_report+0x10d/0x610 mm/kasan/report.c:475
 kasan_report+0x8e/0xc0 mm/kasan/report.c:588
 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]
 bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]
 bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889
 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757
 bfq_init_rq block/bfq-iosched.c:6876 [inline]
 bfq_insert_request block/bfq-iosched.c:6254 [inline]
 bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304
 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593
 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502
 process_one_work kernel/workqueue.c:2627 [inline]
 process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700
 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781
 kthread+0x33c/0x440 kernel/kthread.c:388
 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305
 &lt;/TASK&gt;

Allocated by task 20776:
 kasan_save_stack+0x20/0x40 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328
 kasan_slab_alloc include/linux/kasan.h:188 [inline]
 slab_post_alloc_hook mm/slab.h:763 [inline]
 slab_alloc_node mm/slub.c:3458 [inline]
 kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503
 ioc_create_icq block/blk-ioc.c:370 [inline]
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-47706</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()

Blamed commit accidentally removed a check for rt-&gt;rt6i_idev being NULL,
as spotted by syzbot:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]
 RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914
Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df &lt;80&gt; 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06
RSP: 0018:ffffc900047374e0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0
RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c
R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18
R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930
FS:  0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856
 addrconf_notify+0x3cb/0x1020
  notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93
  call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]
  call_netdevice_notifiers net/core/dev.c:2046 [inline]
  unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352
  unregister_netdevice_many net/core/dev.c:11414 [inline]
  unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289
  unregister_netdevice include/linux/netdevice.h:3129 [inline]
  __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685
  tun_detach drivers/net/tun.c:701 [inline]
  tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510
  __fput+0x24a/0x8a0 fs/file_table.c:422
  task_work_run+0x24f/0x310 kernel/task_work.c:228
  exit_task_work include/linux/task_work.h:40 [inline]
  do_exit+0xa2f/0x27f0 kernel/exit.c:882
  do_group_exit+0x207/0x2c0 kernel/exit.c:1031
  __do_sys_exit_group kernel/exit.c:1042 [inline]
  __se_sys_exit_group kernel/exit.c:1040 [inline]
  __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040
  x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f1acc77def9
Code: Unable to access opcode bytes at 0x7f1acc77decf.
RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043
RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0
 &lt;/TASK&gt;
Modules linked in:
---[ end trace 0000000000000000 ]---
 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]
 RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914
Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df &lt;80&gt; 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06
RSP: 0018:ffffc900047374e0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0
R
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-47707</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: use two-phase skb reclamation in ieee80211_do_stop()

Since '__dev_queue_xmit()' should be called with interrupts enabled,
the following backtrace:

ieee80211_do_stop()
 ...
 spin_lock_irqsave(&amp;local-&gt;queue_stop_reason_lock, flags)
 ...
 ieee80211_free_txskb()
  ieee80211_report_used_skb()
   ieee80211_report_ack_skb()
    cfg80211_mgmt_tx_status_ext()
     nl80211_frame_tx_status()
      genlmsg_multicast_netns()
       genlmsg_multicast_netns_filtered()
        nlmsg_multicast_filtered()
	 netlink_broadcast_filtered()
	  do_one_broadcast()
	   netlink_broadcast_deliver()
	    __netlink_sendskb()
	     netlink_deliver_tap()
	      __netlink_deliver_tap_skb()
	       dev_queue_xmit()
	        __dev_queue_xmit() ; with IRQS disabled
 ...
 spin_unlock_irqrestore(&amp;local-&gt;queue_stop_reason_lock, flags)

issues the warning (as reported by syzbot reproducer):

WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120

Fix this by implementing a two-phase skb reclamation in
'ieee80211_do_stop()', where actual work is performed
outside of a section with interrupts disabled.</Note>
    </Notes>
    <CVE>CVE-2024-47713</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled

Fix missuse of spin_lock_irq()/spin_unlock_irq() when
spin_lock_irqsave()/spin_lock_irqrestore() was hold.

This was discovered through the lock debugging, and the corresponding
log is as follows:

raw_local_irq_restore() called with IRQs enabled
WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40
...
Call trace:
 warn_bogus_irq_restore+0x30/0x40
 _raw_spin_unlock_irqrestore+0x84/0xc8
 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]
 hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]
 hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2]
 create_qp+0x138/0x258
 ib_create_qp_kernel+0x50/0xe8
 create_mad_qp+0xa8/0x128
 ib_mad_port_open+0x218/0x448
 ib_mad_init_device+0x70/0x1f8
 add_client_context+0xfc/0x220
 enable_device_and_get+0xd0/0x140
 ib_register_device.part.0+0xf4/0x1c8
 ib_register_device+0x34/0x50
 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2]
 hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2]
 __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2]
 hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]</Note>
    </Notes>
    <CVE>CVE-2024-47735</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfsd: call cache_put if xdr_reserve_space returns NULL

If not enough buffer space available, but idmap_lookup has triggered
lookup_fn which calls cache_get and returns successfully. Then we
missed to call cache_put here which pairs with cache_get.

Reviwed-by: Jeff Layton &lt;jlayton@kernel.org&gt;</Note>
    </Notes>
    <CVE>CVE-2024-47737</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_loader: Block path traversal

Most firmware names are hardcoded strings, or are constructed from fairly
constrained format strings where the dynamic parts are just some hex
numbers or such.

However, there are a couple codepaths in the kernel where firmware file
names contain string components that are passed through from a device or
semi-privileged userspace; the ones I could find (not counting interfaces
that require root privileges) are:

 - lpfc_sli4_request_firmware_update() seems to construct the firmware
   filename from "ModelName", a string that was previously parsed out of
   some descriptor ("Vital Product Data") in lpfc_fill_vpd()
 - nfp_net_fw_find() seems to construct a firmware filename from a model
   name coming from nfp_hwinfo_lookup(pf-&gt;hwinfo, "nffw.partno"), which I
   think parses some descriptor that was read from the device.
   (But this case likely isn't exploitable because the format string looks
   like "netronome/nic_%s", and there shouldn't be any *folders* starting
   with "netronome/nic_". The previous case was different because there,
   the "%s" is *at the start* of the format string.)
 - module_flash_fw_schedule() is reachable from the
   ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as
   GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is
   enough to pass the privilege check), and takes a userspace-provided
   firmware name.
   (But I think to reach this case, you need to have CAP_NET_ADMIN over a
   network namespace that a special kind of ethernet device is mapped into,
   so I think this is not a viable attack path in practice.)

Fix it by rejecting any firmware names containing ".." path components.

For what it's worth, I went looking and haven't found any USB device
drivers that use the firmware loader dangerously.</Note>
    </Notes>
    <CVE>CVE-2024-47742</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm: call the security_mmap_file() LSM hook in remap_file_pages()

The remap_file_pages syscall handler calls do_mmap() directly, which
doesn't contain the LSM security check. And if the process has called
personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for
RW pages, this will actually result in remapping the pages to RWX,
bypassing a W^X policy enforced by SELinux.

So we should check prot by security_mmap_file LSM hook in the
remap_file_pages syscall handler before do_mmap() is called. Otherwise, it
potentially permits an attacker to bypass a W^X policy enforced by
SELinux.

The bypass is similar to CVE-2016-10044, which bypass the same thing via
AIO and can be found in [1].

The PoC:

$ cat &gt; test.c

int main(void) {
	size_t pagesz = sysconf(_SC_PAGE_SIZE);
	int mfd = syscall(SYS_memfd_create, "test", 0);
	const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE,
		MAP_SHARED, mfd, 0);
	unsigned int old = syscall(SYS_personality, 0xffffffff);
	syscall(SYS_personality, READ_IMPLIES_EXEC | old);
	syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0);
	syscall(SYS_personality, old);
	// show the RWX page exists even if W^X policy is enforced
	int fd = open("/proc/self/maps", O_RDONLY);
	unsigned char buf2[1024];
	while (1) {
		int ret = read(fd, buf2, 1024);
		if (ret &lt;= 0) break;
		write(1, buf2, ret);
	}
	close(fd);
}

$ gcc test.c -o test
$ ./test | grep rwx
7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)

[PM: subject line tweaks]</Note>
    </Notes>
    <CVE>CVE-2024-47745</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/cxgb4: Added NULL check for lookup_atid

The lookup_atid() function can return NULL if the ATID is
invalid or does not exist in the identifier table, which
could lead to dereferencing a null pointer without a
check in the `act_establish()` and `act_open_rpl()` functions.
Add a NULL check to prevent null pointer dereferencing.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-47749</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Vim is an open source, command line text editor. A use-after-free was found in Vim &lt; 9.1.0764. When closing a buffer (visible in a window) a BufWinLeave auto command can cause an use-after-free if this auto command happens to re-open the same buffer in a new split window. Impact is low since the user must have intentionally set up such a strange auto command and run some buffer unload commands. However this may lead to a crash. This issue has been addressed in version 9.1.0764 and all users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2024-47814</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:vim-9.1.0836-17.38.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:vim-data-common-9.1.0836-17.38.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:

tpm: Clean up TPM space after command failure

tpm_dev_transmit prepares the TPM space before attempting command
transmission. However if the command fails no rollback of this
preparation is done. This can result in transient handles being leaked
if the device is subsequently closed with no further commands performed.

Fix this by flushing the space in the event of command transmission
failure.</Note>
    </Notes>
    <CVE>CVE-2024-49851</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption

The TPM event log table is a Linux specific construct, where the data
produced by the GetEventLog() boot service is cached in memory, and
passed on to the OS using an EFI configuration table.

The use of EFI_LOADER_DATA here results in the region being left
unreserved in the E820 memory map constructed by the EFI stub, and this
is the memory description that is passed on to the incoming kernel by
kexec, which is therefore unaware that the region should be reserved.

Even though the utility of the TPM2 event log after a kexec is
questionable, any corruption might send the parsing code off into the
weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY
instead, which is always treated as reserved by the E820 conversion
logic.</Note>
    </Notes>
    <CVE>CVE-2024-49858</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ACPI: sysfs: validate return type of _STR method

Only buffer objects are valid return values of _STR.

If something else is returned description_show() will access invalid
memory.</Note>
    </Notes>
    <CVE>CVE-2024-49860</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

btrfs: fix a NULL pointer dereference when failed to start a new trasacntion

[BUG]
Syzbot reported a NULL pointer dereference with the following crash:

  FAULT_INJECTION: forcing a failure.
   start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676
   prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642
   relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678
  ...
  BTRFS info (device loop0): balance: ended with status: -12
  Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI
  KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667]
  RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926
  Call Trace:
   &lt;TASK&gt;
   commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496
   btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430
   del_balance_item fs/btrfs/volumes.c:3678 [inline]
   reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742
   btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574
   btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673
   vfs_ioctl fs/ioctl.c:51 [inline]
   __do_sys_ioctl fs/ioctl.c:907 [inline]
   __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
   entry_SYSCALL_64_after_hwframe+0x77/0x7f

[CAUSE]
The allocation failure happens at the start_transaction() inside
prepare_to_relocate(), and during the error handling we call
unset_reloc_control(), which makes fs_info-&gt;balance_ctl to be NULL.

Then we continue the error path cleanup in btrfs_balance() by calling
reset_balance_state() which will call del_balance_item() to fully delete
the balance item in the root tree.

However during the small window between set_reloc_contrl() and
unset_reloc_control(), we can have a subvolume tree update and created a
reloc_root for that subvolume.

Then we go into the final btrfs_commit_transaction() of
del_balance_item(), and into btrfs_update_reloc_root() inside
commit_fs_roots().

That function checks if fs_info-&gt;reloc_ctl is in the merge_reloc_tree
stage, but since fs_info-&gt;reloc_ctl is NULL, it results a NULL pointer
dereference.

[FIX]
Just add extra check on fs_info-&gt;reloc_ctl inside
btrfs_update_reloc_root(), before checking
fs_info-&gt;reloc_ctl-&gt;merge_reloc_tree.

That DEAD_RELOC_TREE handling is to prevent further modification to the
reloc tree during merge stage, but since there is no reloc_ctl at all,
we do not need to bother that.</Note>
    </Notes>
    <CVE>CVE-2024-49868</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate

When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger
NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if
bh is NULL.</Note>
    </Notes>
    <CVE>CVE-2024-49877</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: update orig_path in ext4_find_extent()

In ext4_find_extent(), if the path is not big enough, we free it and set
*orig_path to NULL. But after reallocating and successfully initializing
the path, we don't update *orig_path, in which case the caller gets a
valid path but a NULL ppath, and this may cause a NULL pointer dereference
or a path memory leak. For example:

ext4_split_extent
  path = *ppath = 2000
  ext4_find_extent
    if (depth &gt; path[0].p_maxdepth)
      kfree(path = 2000);
      *orig_path = path = NULL;
      path = kcalloc() = 3000
  ext4_split_extent_at(*ppath = NULL)
    path = *ppath;
    ex = path[depth].p_ext;
    // NULL pointer dereference!

==================================================================
BUG: kernel NULL pointer dereference, address: 0000000000000010
CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847
RIP: 0010:ext4_split_extent_at+0x6d/0x560
Call Trace:
 &lt;TASK&gt;
 ext4_split_extent.isra.0+0xcb/0x1b0
 ext4_ext_convert_to_initialized+0x168/0x6c0
 ext4_ext_handle_unwritten_extents+0x325/0x4d0
 ext4_ext_map_blocks+0x520/0xdb0
 ext4_map_blocks+0x2b0/0x690
 ext4_iomap_begin+0x20e/0x2c0
[...]
==================================================================

Therefore, *orig_path is updated when the extent lookup succeeds, so that
the caller can safely use path or *ppath.</Note>
    </Notes>
    <CVE>CVE-2024-49881</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 double brelse() the buffer of the extents path

In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been
released, otherwise it may be released twice. An example of what triggers
this is as follows:

  split2    map    split1
|--------|-------|--------|

ext4_ext_map_blocks
 ext4_ext_handle_unwritten_extents
  ext4_split_convert_extents
   // path-&gt;p_depth == 0
   ext4_split_extent
     // 1. do split1
     ext4_split_extent_at
       |ext4_ext_insert_extent
       |  ext4_ext_create_new_leaf
       |    ext4_ext_grow_indepth
       |      le16_add_cpu(&amp;neh-&gt;eh_depth, 1)
       |    ext4_find_extent
       |      // return -ENOMEM
       |// get error and try zeroout
       |path = ext4_find_extent
       |  path-&gt;p_depth = 1
       |ext4_ext_try_to_merge
       |  ext4_ext_try_to_merge_up
       |    path-&gt;p_depth = 0
       |    brelse(path[1].p_bh)  ---&gt; not set to NULL here
       |// zeroout success
     // 2. update path
     ext4_find_extent
     // 3. do split2
     ext4_split_extent_at
       ext4_ext_insert_extent
         ext4_ext_create_new_leaf
           ext4_ext_grow_indepth
             le16_add_cpu(&amp;neh-&gt;eh_depth, 1)
           ext4_find_extent
             path[0].p_bh = NULL;
             path-&gt;p_depth = 1
             read_extent_tree_block  ---&gt; return err
             // path[1].p_bh is still the old value
             ext4_free_ext_path
               ext4_ext_drop_refs
                 // path-&gt;p_depth == 1
                 brelse(path[1].p_bh)  ---&gt; brelse a buffer twice

Finally got the following WARRNING when removing the buffer from lru:

============================================
VFS: brelse: Trying to free free buffer
WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90
CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716
RIP: 0010:__brelse+0x58/0x90
Call Trace:
 &lt;TASK&gt;
 __find_get_block+0x6e7/0x810
 bdev_getblk+0x2b/0x480
 __ext4_get_inode_loc+0x48a/0x1240
 ext4_get_inode_loc+0xb2/0x150
 ext4_reserve_inode_write+0xb7/0x230
 __ext4_mark_inode_dirty+0x144/0x6a0
 ext4_ext_insert_extent+0x9c8/0x3230
 ext4_ext_map_blocks+0xf45/0x2dc0
 ext4_map_blocks+0x724/0x1700
 ext4_do_writepages+0x12d6/0x2a70
[...]
============================================</Note>
    </Notes>
    <CVE>CVE-2024-49882</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: aovid use-after-free in ext4_ext_insert_extent()

As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is
reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and
cause UAF. Below is a sample trace with dummy values:

ext4_ext_insert_extent
  path = *ppath = 2000
  ext4_ext_create_new_leaf(ppath)
    ext4_find_extent(ppath)
      path = *ppath = 2000
      if (depth &gt; path[0].p_maxdepth)
            kfree(path = 2000);
            *ppath = path = NULL;
      path = kcalloc() = 3000
      *ppath = 3000;
      return path;
  /* here path is still 2000, UAF! */
  eh = path[depth].p_hdr

==================================================================
BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330
Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179
CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866
Call Trace:
 &lt;TASK&gt;
 ext4_ext_insert_extent+0x26d4/0x3330
 ext4_ext_map_blocks+0xe22/0x2d40
 ext4_map_blocks+0x71e/0x1700
 ext4_do_writepages+0x1290/0x2800
[...]

Allocated by task 179:
 ext4_find_extent+0x81c/0x1f70
 ext4_ext_map_blocks+0x146/0x2d40
 ext4_map_blocks+0x71e/0x1700
 ext4_do_writepages+0x1290/0x2800
 ext4_writepages+0x26d/0x4e0
 do_writepages+0x175/0x700
[...]

Freed by task 179:
 kfree+0xcb/0x240
 ext4_find_extent+0x7c0/0x1f70
 ext4_ext_insert_extent+0xa26/0x3330
 ext4_ext_map_blocks+0xe22/0x2d40
 ext4_map_blocks+0x71e/0x1700
 ext4_do_writepages+0x1290/0x2800
 ext4_writepages+0x26d/0x4e0
 do_writepages+0x175/0x700
[...]
==================================================================

So use *ppath to update the path to avoid the above problem.</Note>
    </Notes>
    <CVE>CVE-2024-49883</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: fix slab-use-after-free in ext4_split_extent_at()

We hit the following use-after-free:

==================================================================
BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0
Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40
CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724
Call Trace:
 &lt;TASK&gt;
 kasan_report+0x93/0xc0
 ext4_split_extent_at+0xba8/0xcc0
 ext4_split_extent.isra.0+0x18f/0x500
 ext4_split_convert_extents+0x275/0x750
 ext4_ext_handle_unwritten_extents+0x73e/0x1580
 ext4_ext_map_blocks+0xe20/0x2dc0
 ext4_map_blocks+0x724/0x1700
 ext4_do_writepages+0x12d6/0x2a70
[...]

Allocated by task 40:
 __kmalloc_noprof+0x1ac/0x480
 ext4_find_extent+0xf3b/0x1e70
 ext4_ext_map_blocks+0x188/0x2dc0
 ext4_map_blocks+0x724/0x1700
 ext4_do_writepages+0x12d6/0x2a70
[...]

Freed by task 40:
 kfree+0xf1/0x2b0
 ext4_find_extent+0xa71/0x1e70
 ext4_ext_insert_extent+0xa22/0x3260
 ext4_split_extent_at+0x3ef/0xcc0
 ext4_split_extent.isra.0+0x18f/0x500
 ext4_split_convert_extents+0x275/0x750
 ext4_ext_handle_unwritten_extents+0x73e/0x1580
 ext4_ext_map_blocks+0xe20/0x2dc0
 ext4_map_blocks+0x724/0x1700
 ext4_do_writepages+0x12d6/0x2a70
[...]
==================================================================

The flow of issue triggering is as follows:

ext4_split_extent_at
  path = *ppath
  ext4_ext_insert_extent(ppath)
    ext4_ext_create_new_leaf(ppath)
      ext4_find_extent(orig_path)
        path = *orig_path
        read_extent_tree_block
          // return -ENOMEM or -EIO
        ext4_free_ext_path(path)
          kfree(path)
        *orig_path = NULL
  a. If err is -ENOMEM:
  ext4_ext_dirty(path + path-&gt;p_depth)
  // path use-after-free !!!
  b. If err is -EIO and we have EXT_DEBUG defined:
  ext4_ext_show_leaf(path)
    eh = path[depth].p_hdr
    // path also use-after-free !!!

So when trying to zeroout or fix the extent length, call ext4_find_extent()
to update the path.

In addition we use *ppath directly as an ext4_ext_show_leaf() input to
avoid possible use-after-free when EXT_DEBUG is defined, and to avoid
unnecessary path updates.</Note>
    </Notes>
    <CVE>CVE-2024-49884</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pm: ensure the fw_info is not null before using it

This resolves the dereference null return value warning
reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49890</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Validate hdwq pointers before dereferencing in reset/errata paths

When the HBA is undergoing a reset or is handling an errata event, NULL ptr
dereference crashes may occur in routines such as
lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or
lpfc_abort_handler().

Add NULL ptr checks before dereferencing hdwq pointers that may have been
freed due to operations colliding with a reset or errata event handler.</Note>
    </Notes>
    <CVE>CVE-2024-49891</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 index out of bounds in degamma hardware format translation

Fixes index out of bounds issue in
`cm_helper_translate_curve_to_degamma_hw_format` function. The issue
could occur when the index 'i' exceeds the number of transfer function
points (TRANSFER_FUNC_POINTS).

The fix adds a check to ensure 'i' is within bounds before accessing the
transfer function points. If 'i' is out of bounds the function returns
false to indicate an error.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf-&gt;tf_pts.red' 1025 &lt;= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf-&gt;tf_pts.green' 1025 &lt;= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf-&gt;tf_pts.blue' 1025 &lt;= s32max</Note>
    </Notes>
    <CVE>CVE-2024-49894</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check stream before comparing them

[WHAT &amp; HOW]
amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is
necessary to check for null before dereferencing them.

This fixes 1 FORWARD_NULL issue reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49896</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/msm/adreno: Assign msm_gpu-&gt;pdev earlier to avoid nullptrs

There are some cases, such as the one uncovered by Commit 46d4efcccc68
("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails")
where

msm_gpu_cleanup() : platform_set_drvdata(gpu-&gt;pdev, NULL);

is called on gpu-&gt;pdev == NULL, as the GPU device has not been fully
initialized yet.

Turns out that there's more than just the aforementioned path that
causes this to happen (e.g. the case when there's speedbin data in the
catalog, but opp-supported-hw is missing in DT).

Assigning msm_gpu-&gt;pdev earlier seems like the least painful solution
to this, therefore do so.

Patchwork: https://patchwork.freedesktop.org/patch/602742/</Note>
    </Notes>
    <CVE>CVE-2024-49901</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check null pointers before multiple uses

[WHAT &amp; HOW]
Poniters, such as stream_enc and dc-&gt;bw_vbios, are null checked previously
in the same function, so Coverity warns "implies that stream_enc and
dc-&gt;bw_vbios might be null". They are used multiple times in the
subsequent code and need to be checked.

This fixes 10 FORWARD_NULL issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49920</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check null pointers before used

[WHAT &amp; HOW]
Poniters, such as dc-&gt;clk_mgr, are null checked previously in the same
function, so Coverity warns "implies that "dc-&gt;clk_mgr" might be null".
As a result, these pointers need to be checked when used again.

This fixes 10 FORWARD_NULL issues reported by Coverity.</Note>
    </Notes>
    <CVE>CVE-2024-49921</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fbdev: efifb: Register sysfs groups through driver core

The driver core can register and cleanup sysfs groups already.
Make use of that functionality to simplify the error handling and
cleanup.

Also avoid a UAF race during unregistering where the sysctl attributes
were usable after the info struct was freed.</Note>
    </Notes>
    <CVE>CVE-2024-49925</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: avoid NULL pointer dereference

iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta
pointer is not NULL.
It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is
dereferencing the ieee80211_sta pointer.
If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL
pointer.
Fix this by checking the sta pointer before retrieving the mvmsta
from it. If sta is not NULL, then mvmsta isn't either.</Note>
    </Notes>
    <CVE>CVE-2024-49929</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/xen-netback: prevent UAF in xenvif_flush_hash()

During the list_for_each_entry_rcu iteration call of xenvif_flush_hash,
kfree_rcu does not exist inside the rcu read critical section, so if
kfree_rcu is called when the rcu grace period ends during the iteration,
UAF occurs when accessing head-&gt;next after the entry becomes free.

Therefore, to solve this, you need to change it to list_for_each_entry_safe.</Note>
    </Notes>
    <CVE>CVE-2024-49936</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit

Syzbot points out that skb_trim() has a sanity check on the existing length of
the skb, which can be uninitialised in some error paths. The intent here is
clearly just to reset the length to zero before resubmitting, so switch to
calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length()
already contains a call to skb_reset_tail_pointer(), so remove the redundant
call.

The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar
usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.</Note>
    </Notes>
    <CVE>CVE-2024-49938</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ncsi: Disable the ncsi work before freeing the associated structure

The work function can run after the ncsi device is freed, resulting
in use-after-free bugs or kernel panic.</Note>
    </Notes>
    <CVE>CVE-2024-49945</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: avoid potential underflow in qdisc_pkt_len_init() with UFO

After commit 7c6d2ecbda83 ("net: be more gentle about silly gso
requests coming from user") virtio_net_hdr_to_skb() had sanity check
to detect malicious attempts from user space to cook a bad GSO packet.

Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count
transport header in UFO") while fixing one issue, allowed user space
to cook a GSO packet with the following characteristic :

IPv4 SKB_GSO_UDP, gso_size=3, skb-&gt;len = 28.

When this packet arrives in qdisc_pkt_len_init(), we end up
with hdr_len = 28 (IPv4 header + UDP header), matching skb-&gt;len

Then the following sets gso_segs to 0 :

gso_segs = DIV_ROUND_UP(skb-&gt;len - hdr_len,
                        shinfo-&gt;gso_size);

Then later we set qdisc_skb_cb(skb)-&gt;pkt_len to back to zero :/

qdisc_skb_cb(skb)-&gt;pkt_len += (gso_segs - 1) * hdr_len;

This leads to the following crash in fq_codel [1]

qdisc_pkt_len_init() is best effort, we only want an estimation
of the bytes sent on the wire, not crashing the kernel.

This patch is fixing this particular issue, a following one
adds more sanity checks for another potential bug.

[1]
[   70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000
[   70.724561] #PF: supervisor read access in kernel mode
[   70.724561] #PF: error_code(0x0000) - not-present page
[   70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0
[   70.724561] Oops: Oops: 0000 [#1] SMP NOPTI
[   70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991
[   70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[   70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel
[ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 &lt;49&gt; 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49
All code
========
   0:	24 08                	and    $0x8,%al
   2:	49 c1 e1 06          	shl    $0x6,%r9
   6:	44 89 7c 24 18       	mov    %r15d,0x18(%rsp)
   b:	45 31 ed             	xor    %r13d,%r13d
   e:	45 31 c0             	xor    %r8d,%r8d
  11:	31 ff                	xor    %edi,%edi
  13:	89 44 24 14          	mov    %eax,0x14(%rsp)
  17:	4c 03 8b 90 01 00 00 	add    0x190(%rbx),%r9
  1e:	eb 04                	jmp    0x24
  20:	39 ca                	cmp    %ecx,%edx
  22:	73 37                	jae    0x5b
  24:	4d 8b 39             	mov    (%r9),%r15
  27:	83 c7 01             	add    $0x1,%edi
  2a:*	49 8b 17             	mov    (%r15),%rdx		&lt;-- trapping instruction
  2d:	49 89 11             	mov    %rdx,(%r9)
  30:	41 8b 57 28          	mov    0x28(%r15),%edx
  34:	45 8b 5f 34          	mov    0x34(%r15),%r11d
  38:	49 c7 07 00 00 00 00 	movq   $0x0,(%r15)
  3f:	49                   	rex.WB

Code starting with the faulting instruction
===========================================
   0:	49 8b 17             	mov    (%r15),%rdx
   3:	49 89 11             	mov    %rdx,(%r9)
   6:	41 8b 57 28          	mov    0x28(%r15),%edx
   a:	45 8b 5f 34          	mov    0x34(%r15),%r11d
   e:	49 c7 07 00 00 00 00 	movq   $0x0,(%r15)
  15:	49                   	rex.WB
[   70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202
[   70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000
[   70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
[   70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000
[   70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58
[   70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000
[   70.724561] FS:  000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000
[   70.724561] CS:  0010 DS: 0000 ES: 0000 C
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-49949</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix uaf in l2cap_connect

[Syzbot reported]
BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949
Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54

CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Workqueue: hci2 hci_rx_work
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:93 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0xc3/0x620 mm/kasan/report.c:488
 kasan_report+0xd9/0x110 mm/kasan/report.c:601
 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949
 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline]
 l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline]
 l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline]
 l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825
 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514
 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline]
 hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028
 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231
 process_scheduled_works kernel/workqueue.c:3312 [inline]
 worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389
 kthread+0x2c1/0x3a0 kernel/kthread.c:389
 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
...

Freed by task 5245:
 kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
 kasan_save_track+0x14/0x30 mm/kasan/common.c:68
 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579
 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240
 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256
 kasan_slab_free include/linux/kasan.h:184 [inline]
 slab_free_hook mm/slub.c:2256 [inline]
 slab_free mm/slub.c:4477 [inline]
 kfree+0x12a/0x3b0 mm/slub.c:4598
 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline]
 kref_put include/linux/kref.h:65 [inline]
 l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline]
 l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802
 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241
 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline]
 hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265
 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583
 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917
 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328
 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231
 process_scheduled_works kernel/workqueue.c:3312 [inline]
 worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389
 kthread+0x2c1/0x3a0 kernel/kthread.c:389
 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244</Note>
    </Notes>
    <CVE>CVE-2024-49950</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: prevent nf_skb_duplicated corruption

syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write
per-cpu variable nf_skb_duplicated in an unsafe way [1].

Disabling preemption as hinted by the splat is not enough,
we have to disable soft interrupts as well.

[1]
BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316
 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87
CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:93 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
  check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49
  nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87
  nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30
  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
  nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288
  nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23
  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
  nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626
  nf_hook+0x2c4/0x450 include/linux/netfilter.h:269
  NF_HOOK_COND include/linux/netfilter.h:302 [inline]
  ip_output+0x185/0x230 net/ipv4/ip_output.c:433
  ip_local_out net/ipv4/ip_output.c:129 [inline]
  ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495
  udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981
  udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x1a6/0x270 net/socket.c:745
  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597
  ___sys_sendmsg net/socket.c:2651 [inline]
  __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737
  __do_sys_sendmmsg net/socket.c:2766 [inline]
  __se_sys_sendmmsg net/socket.c:2763 [inline]
  __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4ce4f7def9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9
RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006
RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-49952</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix null-ptr-deref when journal load failed.

During the mounting process, if journal_reset() fails because of too short
journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. 
Subsequently, ocfs2_journal_shutdown() calls
jbd2_journal_flush()-&gt;jbd2_cleanup_journal_tail()-&gt;
__jbd2_update_log_tail()-&gt;jbd2_journal_update_sb_log_tail()
-&gt;lock_buffer(journal-&gt;j_sb_buffer), resulting in a null-pointer
dereference error.

To resolve this issue, we should check the JBD2_LOADED flag to ensure the
journal was properly loaded.  Additionally, use journal instead of
osb-&gt;journal directly to simplify the code.</Note>
    </Notes>
    <CVE>CVE-2024-49957</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: reserve space for inline xattr before attaching reflink tree

One of our customers reported a crash and a corrupted ocfs2 filesystem. 
The crash was due to the detection of corruption.  Upon troubleshooting,
the fsck -fn output showed the below corruption

[EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record,
but fsck believes the largest valid value is 227.  Clamp the next record value? n

The stat output from the debugfs.ocfs2 showed the following corruption
where the "Next Free Rec:" had overshot the "Count:" in the root metadata
block.

        Inode: 33080590   Mode: 0640   Generation: 2619713622 (0x9c25a856)
        FS Generation: 904309833 (0x35e6ac49)
        CRC32: 00000000   ECC: 0000
        Type: Regular   Attr: 0x0   Flags: Valid
        Dynamic Features: (0x16) HasXattr InlineXattr Refcounted
        Extended Attributes Block: 0  Extended Attributes Inline Size: 256
        User: 0 (root)   Group: 0 (root)   Size: 281320357888
        Links: 1   Clusters: 141738
        ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024
        atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024
        mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024
        dtime: 0x0 -- Wed Dec 31 17:00:00 1969
        Refcount Block: 2777346
        Last Extblk: 2886943   Orphan Slot: 0
        Sub Alloc Slot: 0   Sub Alloc Bit: 14
        Tree Depth: 1   Count: 227   Next Free Rec: 230
        ## Offset        Clusters       Block#
        0  0             2310           2776351
        1  2310          2139           2777375
        2  4449          1221           2778399
        3  5670          731            2779423
        4  6401          566            2780447
        .......          ....           .......
        .......          ....           .......

The issue was in the reflink workfow while reserving space for inline
xattr.  The problematic function is ocfs2_reflink_xattr_inline().  By the
time this function is called the reflink tree is already recreated at the
destination inode from the source inode.  At this point, this function
reserves space for inline xattrs at the destination inode without even
checking if there is space at the root metadata block.  It simply reduces
the l_count from 243 to 227 thereby making space of 256 bytes for inline
xattr whereas the inode already has extents beyond this index (in this
case up to 230), thereby causing corruption.

The fix for this is to reserve space for inline metadata at the destination
inode before the reflink tree gets recreated. The customer has verified the
fix.</Note>
    </Notes>
    <CVE>CVE-2024-49958</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error

In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()
to recover some journal space. But if an error occurs while executing
jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free
space right away, we try other branches, and if j_committing_transaction
is NULL (i.e., the tid is 0), we will get the following complain:

============================================
JBD2: I/O error when updating journal superblock for sdd-8.
__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available
__jbd2_log_wait_for_space: no way to get more journal space in sdd-8
------------[ cut here ]------------
WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0
Modules linked in:
CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1
RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0
Call Trace:
 &lt;TASK&gt;
 add_transaction_credits+0x5d1/0x5e0
 start_this_handle+0x1ef/0x6a0
 jbd2__journal_start+0x18b/0x340
 ext4_dirty_inode+0x5d/0xb0
 __mark_inode_dirty+0xe4/0x5d0
 generic_update_time+0x60/0x70
[...]
============================================

So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to
clean up at the moment, continue to try to reclaim free space in other ways.

Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt
when updating journal superblock fails") to make jbd2_cleanup_journal_tail
return the correct error code.</Note>
    </Notes>
    <CVE>CVE-2024-49959</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()

ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0

ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause
NULL pointer dereference later.

[ rjw: Subject and changelog edits ]</Note>
    </Notes>
    <CVE>CVE-2024-49962</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: remove unreasonable unlock in ocfs2_read_blocks

Patch series "Misc fixes for ocfs2_read_blocks", v5.

This series contains 2 fixes for ocfs2_read_blocks().  The first patch fix
the issue reported by syzbot, which detects bad unlock balance in
ocfs2_read_blocks().  The second patch fixes an issue reported by Heming
Zhao when reviewing above fix.


This patch (of 2):

There was a lock release before exiting, so remove the unreasonable unlock.</Note>
    </Notes>
    <CVE>CVE-2024-49965</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: cancel dqi_sync_work before freeing oinfo

ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the
end, if error occurs after successfully reading global quota, it will
trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:

ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c

This reports that there is an active delayed work when freeing oinfo in
error handling, so cancel dqi_sync_work first.  BTW, return status instead
of -1 when .read_file_info fails.</Note>
    </Notes>
    <CVE>CVE-2024-49966</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-49967</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer

Pass pointer reference to amdgpu_bo_unref to clear the correct pointer,
otherwise amdgpu_bo_unref clear the local variable, the original pointer
not set to NULL, this could cause use-after-free bug.</Note>
    </Notes>
    <CVE>CVE-2024-49991</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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">** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-49995</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix buffer overflow when parsing NFS reparse points

ReparseDataLength is sum of the InodeType size and DataBuffer size.
So to get DataBuffer size it is needed to subtract InodeType's size from
ReparseDataLength.

Function cifs_strndup_from_utf16() is currentlly accessing buf-&gt;DataBuffer
at position after the end of the buffer because it does not subtract
InodeType size from the length. Fix this problem and correctly subtract
variable len.

Member InodeType is present only when reparse buffer is large enough. Check
for ReparseDataLength before accessing InodeType to prevent another invalid
memory access.

Major and minor rdev values are present also only when reparse buffer is
large enough. Check for reparse buffer size before calling reparse_mkdev().</Note>
    </Notes>
    <CVE>CVE-2024-49996</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 i_data_sem unlock order in ext4_ind_migrate()

Fuzzing reports a possible deadlock in jbd2_log_wait_commit.

This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require
synchronous updates because the file descriptor is opened with O_SYNC.
This can lead to the jbd2_journal_stop() function calling
jbd2_might_wait_for_commit(), potentially causing a deadlock if the
EXT4_IOC_MIGRATE call races with a write(2) system call.

This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this
case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the
jbd2_journal_stop function while i_data_sem is locked. This triggers
lockdep because the jbd2_journal_start function might also lock the same
jbd2_handle simultaneously.

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

Rule: add</Note>
    </Notes>
    <CVE>CVE-2024-50006</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: asihpi: Fix potential OOB array access

ASIHPI driver stores some values in the static array upon a response
from the driver, and its index depends on the firmware.  We shouldn't
trust it blindly.

This patch adds a sanity check of the array index to fit in the array
size.</Note>
    </Notes>
    <CVE>CVE-2024-50007</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: Fix an unsafe loop on the list

The kernel may crash when deleting a genetlink family if there are still
listeners for that family:

Oops: Kernel access of bad area, sig: 11 [#1]
  ...
  NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0
  LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0
  Call Trace:
__netlink_clear_multicast_users+0x74/0xc0
genl_unregister_family+0xd4/0x2d0

Change the unsafe loop on the list to a safe one, because inside the
loop there is an element removal from this list.</Note>
    </Notes>
    <CVE>CVE-2024-50024</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

slip: make slhc_remember() more robust against malicious packets

syzbot found that slhc_remember() was missing checks against
malicious packets [1].

slhc_remember() only checked the size of the packet was at least 20,
which is not good enough.

We need to make sure the packet includes the IPv4 and TCP header
that are supposed to be carried.

Add iph and th pointers to make the code more readable.

[1]

BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666
  slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666
  ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455
  ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline]
  ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212
  ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327
  pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379
  sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113
  __release_sock+0x1da/0x330 net/core/sock.c:3072
  release_sock+0x6b/0x250 net/core/sock.c:3626
  pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903
  sock_sendmsg_nosec net/socket.c:729 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:744
  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
  __do_sys_sendmmsg net/socket.c:2771 [inline]
  __se_sys_sendmmsg net/socket.c:2768 [inline]
  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at:
  slab_post_alloc_hook mm/slub.c:4091 [inline]
  slab_alloc_node mm/slub.c:4134 [inline]
  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587
  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678
  alloc_skb include/linux/skbuff.h:1322 [inline]
  sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732
  pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867
  sock_sendmsg_nosec net/socket.c:729 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:744
  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
  __do_sys_sendmmsg net/socket.c:2771 [inline]
  __se_sys_sendmmsg net/socket.c:2768 [inline]
  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024</Note>
    </Notes>
    <CVE>CVE-2024-50033</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ppp: fix ppp_async_encode() illegal access

syzbot reported an issue in ppp_async_encode() [1]

In this case, pppoe_sendmsg() is called with a zero size.
Then ppp_async_encode() is called with an empty skb.

BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]
 BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675
  ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]
  ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675
  ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634
  ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]
  ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304
  pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379
  sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113
  __release_sock+0x1da/0x330 net/core/sock.c:3072
  release_sock+0x6b/0x250 net/core/sock.c:3626
  pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903
  sock_sendmsg_nosec net/socket.c:729 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:744
  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
  __do_sys_sendmmsg net/socket.c:2771 [inline]
  __se_sys_sendmmsg net/socket.c:2768 [inline]
  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at:
  slab_post_alloc_hook mm/slub.c:4092 [inline]
  slab_alloc_node mm/slub.c:4135 [inline]
  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587
  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678
  alloc_skb include/linux/skbuff.h:1322 [inline]
  sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732
  pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867
  sock_sendmsg_nosec net/socket.c:729 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:744
  ____sys_sendmsg+0x903/0xb60 net/socket.c:2602
  ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656
  __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742
  __do_sys_sendmmsg net/socket.c:2771 [inline]
  __se_sys_sendmmsg net/socket.c:2768 [inline]
  __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768
  x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024</Note>
    </Notes>
    <CVE>CVE-2024-50035</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change

rfcomm_sk_state_change attempts to use sock_lock so it must never be
called with it locked but rfcomm_sock_ioctl always attempt to lock it
causing the following trace:

======================================================
WARNING: possible circular locking dependency detected
6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted
------------------------------------------------------
syz-executor386/5093 is trying to acquire lock:
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]
ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73

but task is already holding lock:
ffff88807badfd28 (&amp;d-&gt;lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491</Note>
    </Notes>
    <CVE>CVE-2024-50044</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: br_netfilter: fix panic with metadata_dst skb

Fix a kernel panic in the br_netfilter module when sending untagged
traffic via a VxLAN device.
This happens during the check for fragmentation in br_nf_dev_queue_xmit.

It is dependent on:
1) the br_netfilter module being loaded;
2) net.bridge.bridge-nf-call-iptables set to 1;
3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port;
4) untagged frames with size higher than the VxLAN MTU forwarded/flooded

When forwarding the untagged packet to the VxLAN bridge port, before
the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and
changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type
of dst, i.e., skb_valid_dst(skb) is false, and metadata-&gt;dst.dev is NULL.

Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check
for frames that needs to be fragmented: frames with higher MTU than the
VxLAN device end up calling br_nf_ip_fragment, which in turns call
ip_skb_dst_mtu.

The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst
with valid dst-&gt;dev, thus the crash.

This case was never supported in the first place, so drop the packet
instead.

PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data.
[  176.291791] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000110
[  176.292101] Mem abort info:
[  176.292184]   ESR = 0x0000000096000004
[  176.292322]   EC = 0x25: DABT (current EL), IL = 32 bits
[  176.292530]   SET = 0, FnV = 0
[  176.292709]   EA = 0, S1PTW = 0
[  176.292862]   FSC = 0x04: level 0 translation fault
[  176.293013] Data abort info:
[  176.293104]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[  176.293488]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[  176.293787]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[  176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000
[  176.294166] [0000000000000110] pgd=0000000000000000,
p4d=0000000000000000
[  176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[  176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth
br_netfilter bridge stp llc ipv6 crct10dif_ce
[  176.295923] CPU: 0 PID: 188 Comm: ping Not tainted
6.8.0-rc3-g5b3fbd61b9d1 #2
[  176.296314] Hardware name: linux,dummy-virt (DT)
[  176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[  176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]
[  176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter]
[  176.297636] sp : ffff800080003630
[  176.297743] x29: ffff800080003630 x28: 0000000000000008 x27:
ffff6828c49ad9f8
[  176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24:
00000000000003e8
[  176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21:
ffff6828c3b16d28
[  176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18:
0000000000000014
[  176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15:
0000000095744632
[  176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12:
ffffb7e137926a70
[  176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 :
0000000000000000
[  176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 :
f20e0100bebafeca
[  176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 :
0000000000000000
[  176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 :
ffff6828c7f918f0
[  176.300889] Call trace:
[  176.301123]  br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter]
[  176.301411]  br_nf_post_routing+0x2a8/0x3e4 [br_netfilter]
[  176.301703]  nf_hook_slow+0x48/0x124
[  176.302060]  br_forward_finish+0xc8/0xe8 [bridge]
[  176.302371]  br_nf_hook_thresh+0x124/0x134 [br_netfilter]
[  176.302605]  br_nf_forward_finish+0x118/0x22c [br_netfilter]
[  176.302824]  br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter]
[  176.303136]  br_nf_forward+0x2b8/0x4e0 [br_netfilter]
[  176.303359]  nf_hook_slow+0x48/0x124
[  176.303
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50045</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix UAF in async decryption

Doing an async decryption (large read) crashes with a
slab-use-after-free way down in the crypto API.

Reproducer:
    # mount.cifs -o ...,seal,esize=1 //srv/share /mnt
    # dd if=/mnt/largefile of=/dev/null
    ...
    [  194.196391] ==================================================================
    [  194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110
    [  194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899
    [  194.197707]
    [  194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43
    [  194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014
    [  194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]
    [  194.200032] Call Trace:
    [  194.200191]  &lt;TASK&gt;
    [  194.200327]  dump_stack_lvl+0x4e/0x70
    [  194.200558]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.200809]  print_report+0x174/0x505
    [  194.201040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
    [  194.201352]  ? srso_return_thunk+0x5/0x5f
    [  194.201604]  ? __virt_addr_valid+0xdf/0x1c0
    [  194.201868]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202128]  kasan_report+0xc8/0x150
    [  194.202361]  ? gf128mul_4k_lle+0xc1/0x110
    [  194.202616]  gf128mul_4k_lle+0xc1/0x110
    [  194.202863]  ghash_update+0x184/0x210
    [  194.203103]  shash_ahash_update+0x184/0x2a0
    [  194.203377]  ? __pfx_shash_ahash_update+0x10/0x10
    [  194.203651]  ? srso_return_thunk+0x5/0x5f
    [  194.203877]  ? crypto_gcm_init_common+0x1ba/0x340
    [  194.204142]  gcm_hash_assoc_remain_continue+0x10a/0x140
    [  194.204434]  crypt_message+0xec1/0x10a0 [cifs]
    [  194.206489]  ? __pfx_crypt_message+0x10/0x10 [cifs]
    [  194.208507]  ? srso_return_thunk+0x5/0x5f
    [  194.209205]  ? srso_return_thunk+0x5/0x5f
    [  194.209925]  ? srso_return_thunk+0x5/0x5f
    [  194.210443]  ? srso_return_thunk+0x5/0x5f
    [  194.211037]  decrypt_raw_data+0x15f/0x250 [cifs]
    [  194.212906]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]
    [  194.214670]  ? srso_return_thunk+0x5/0x5f
    [  194.215193]  smb2_decrypt_offload+0x12a/0x6c0 [cifs]

This is because TFM is being used in parallel.

Fix this by allocating a new AEAD TFM for async decryption, but keep
the existing one for synchronous READ cases (similar to what is done
in smb3_calc_signature()).

Also remove the calls to aead_request_set_callback() and
crypto_wait_req() since it's always going to be a synchronous operation.</Note>
    </Notes>
    <CVE>CVE-2024-50047</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

driver core: bus: Fix double free in driver API bus_register()

For bus_register(), any error which happens after kset_register() will
cause that @priv are freed twice, fixed by setting @priv with NULL after
the first free.</Note>
    </Notes>
    <CVE>CVE-2024-50055</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: protect uart_port_dtr_rts() in uart_shutdown() too

Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part
3) added few uport == NULL checks. It added one to uart_shutdown(), so
the commit assumes, uport can be NULL in there. But right after that
protection, there is an unprotected "uart_port_dtr_rts(uport, false);"
call. That is invoked only if HUPCL is set, so I assume that is the
reason why we do not see lots of these reports.

Or it cannot be NULL at this point at all for some reason :P.

Until the above is investigated, stay on the safe side and move this
dereference to the if too.

I got this inconsistency from Coverity under CID 1585130. Thanks.</Note>
    </Notes>
    <CVE>CVE-2024-50058</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tty: n_gsm: Fix use-after-free in gsm_cleanup_mux

BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0
drivers/tty/n_gsm.c:3160 [n_gsm]
Read of size 8 at addr ffff88815fe99c00 by task poc/3379
CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56
Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 11/12/2020
Call Trace:
 &lt;TASK&gt;
 gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]
 __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm]
 __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389
 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500
 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846
 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161
 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]
 _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107
 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm]
 ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195
 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79
 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338
 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805
 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818

Allocated by task 65:
 gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm]
 gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm]
 gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm]
 gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm]
 tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391
 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39
 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445
 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229
 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391
 kthread+0x2a3/0x370 kernel/kthread.c:389
 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257

Freed by task 3367:
 kfree+0x126/0x420 mm/slub.c:4580
 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]
 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]
 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818

[Analysis]
gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux
can be freed by multi threads through ioctl,which leads
to the occurrence of uaf. Protect it by gsm tx lock.</Note>
    </Notes>
    <CVE>CVE-2024-50073</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

parport: Proper fix for array out-of-bounds access

The recent fix for array out-of-bounds accesses replaced sprintf()
calls blindly with snprintf().  However, since snprintf() returns the
would-be-printed size, not the actually output size, the length
calculation can still go over the given limit.

Use scnprintf() instead of snprintf(), which returns the actually
output letters, for addressing the potential out-of-bounds access
properly.</Note>
    </Notes>
    <CVE>CVE-2024-50074</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/mad: Improve handling of timed out WRs of mad agent

Current timeout handler of mad agent acquires/releases mad_agent_priv
lock for every timed out WRs. This causes heavy locking contention
when higher no. of WRs are to be handled inside timeout handler.

This leads to softlockup with below trace in some use cases where
rdma-cm path is used to establish connection between peer nodes

Trace:
-----
 BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767]
 CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE
     -------  ---  5.14.0-427.13.1.el9_4.x86_64 #1
 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019
 Workqueue: ib_mad1 timeout_sends [ib_core]
 RIP: 0010:__do_softirq+0x78/0x2ac
 RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246
 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f
 RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b
 RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000
 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000
 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040
 FS:  0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 PKRU: 55555554
 Call Trace:
  &lt;IRQ&gt;
  ? show_trace_log_lvl+0x1c4/0x2df
  ? show_trace_log_lvl+0x1c4/0x2df
  ? __irq_exit_rcu+0xa1/0xc0
  ? watchdog_timer_fn+0x1b2/0x210
  ? __pfx_watchdog_timer_fn+0x10/0x10
  ? __hrtimer_run_queues+0x127/0x2c0
  ? hrtimer_interrupt+0xfc/0x210
  ? __sysvec_apic_timer_interrupt+0x5c/0x110
  ? sysvec_apic_timer_interrupt+0x37/0x90
  ? asm_sysvec_apic_timer_interrupt+0x16/0x20
  ? __do_softirq+0x78/0x2ac
  ? __do_softirq+0x60/0x2ac
  __irq_exit_rcu+0xa1/0xc0
  sysvec_call_function_single+0x72/0x90
  &lt;/IRQ&gt;
  &lt;TASK&gt;
  asm_sysvec_call_function_single+0x16/0x20
 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30
 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247
 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800
 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c
 RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000
 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538
 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c
  cm_process_send_error+0x122/0x1d0 [ib_cm]
  timeout_sends+0x1dd/0x270 [ib_core]
  process_one_work+0x1e2/0x3b0
  ? __pfx_worker_thread+0x10/0x10
  worker_thread+0x50/0x3a0
  ? __pfx_worker_thread+0x10/0x10
  kthread+0xdd/0x100
  ? __pfx_kthread+0x10/0x10
  ret_from_fork+0x29/0x50
  &lt;/TASK&gt;

Simplified timeout handler by creating local list of timed out WRs
and invoke send handler post creating the list. The new method acquires/
releases lock once to fetch the list and hence helps to reduce locking
contetiong when processing higher no. of WRs</Note>
    </Notes>
    <CVE>CVE-2024-50095</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: probes: Remove broken LDR (literal) uprobe support

The simulate_ldr_literal() and simulate_ldrsw_literal() functions are
unsafe to use for uprobes. Both functions were originally written for
use with kprobes, and access memory with plain C accesses. When uprobes
was added, these were reused unmodified even though they cannot safely
access user memory.

There are three key problems:

1) The plain C accesses do not have corresponding extable entries, and
   thus if they encounter a fault the kernel will treat these as
   unintentional accesses to user memory, resulting in a BUG() which
   will kill the kernel thread, and likely lead to further issues (e.g.
   lockup or panic()).

2) The plain C accesses are subject to HW PAN and SW PAN, and so when
   either is in use, any attempt to simulate an access to user memory
   will fault. Thus neither simulate_ldr_literal() nor
   simulate_ldrsw_literal() can do anything useful when simulating a
   user instruction on any system with HW PAN or SW PAN.

3) The plain C accesses are privileged, as they run in kernel context,
   and in practice can access a small range of kernel virtual addresses.
   The instructions they simulate have a range of +/-1MiB, and since the
   simulated instructions must itself be a user instructions in the
   TTBR0 address range, these can address the final 1MiB of the TTBR1
   acddress range by wrapping downwards from an address in the first
   1MiB of the TTBR0 address range.

   In contemporary kernels the last 8MiB of TTBR1 address range is
   reserved, and accesses to this will always fault, meaning this is no
   worse than (1).

   Historically, it was theoretically possible for the linear map or
   vmemmap to spill into the final 8MiB of the TTBR1 address range, but
   in practice this is extremely unlikely to occur as this would
   require either:

   * Having enough physical memory to fill the entire linear map all the
     way to the final 1MiB of the TTBR1 address range.

   * Getting unlucky with KASLR randomization of the linear map such
     that the populated region happens to overlap with the last 1MiB of
     the TTBR address range.

   ... and in either case if we were to spill into the final page there
   would be larger problems as the final page would alias with error
   pointers.

Practically speaking, (1) and (2) are the big issues. Given there have
been no reports of problems since the broken code was introduced, it
appears that no-one is relying on probing these instructions with
uprobes.

Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW
(literal), limiting the use of simulate_ldr_literal() and
simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR
(literal) and LDRSW (literal) will be rejected as
arm_probe_decode_insn() will return INSN_REJECTED. In future we can
consider introducing working uprobes support for these instructions, but
this will require more significant work.</Note>
    </Notes>
    <CVE>CVE-2024-50099</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory

Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits
4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't
enforce 32-byte alignment of nCR3.

In the absolute worst case scenario, failure to ignore bits 4:0 can result
in an out-of-bounds read, e.g. if the target page is at the end of a
memslot, and the VMM isn't using guard pages.

Per the APM:

  The CR3 register points to the base address of the page-directory-pointer
  table. The page-directory-pointer table is aligned on a 32-byte boundary,
  with the low 5 address bits 4:0 assumed to be 0.

And the SDM's much more explicit:

  4:0    Ignored

Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow
that is broken.</Note>
    </Notes>
    <CVE>CVE-2024-50115</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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/amd: Guard against bad data for ATIF ACPI method

If a BIOS provides bad data in response to an ATIF method call
this causes a NULL pointer dereference in the caller.

```
? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1))
? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434)
? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2))
? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1))
? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642)
? exc_page_fault (arch/x86/mm/fault.c:1542)
? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)
? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu
? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu
```

It has been encountered on at least one system, so guard for it.

(cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)</Note>
    </Notes>
    <CVE>CVE-2024-50117</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: SCO: Fix UAF on sco_sock_timeout

conn-&gt;sk maybe have been unlinked/freed while waiting for sco_conn_lock
so this checks if the conn-&gt;sk is still valid by checking if it part of
sco_sk_list.</Note>
    </Notes>
    <CVE>CVE-2024-50125</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

nvme-pci: fix race condition between reset and nvme_dev_disable()

nvme_dev_disable() modifies the dev-&gt;online_queues field, therefore
nvme_pci_update_nr_queues() should avoid racing against it, otherwise
we could end up passing invalid values to blk_mq_update_nr_hw_queues().

 WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347
          pci_irq_get_affinity+0x187/0x210
 Workqueue: nvme-reset-wq nvme_reset_work [nvme]
 RIP: 0010:pci_irq_get_affinity+0x187/0x210
 Call Trace:
  &lt;TASK&gt;
  ? blk_mq_pci_map_queues+0x87/0x3c0
  ? pci_irq_get_affinity+0x187/0x210
  blk_mq_pci_map_queues+0x87/0x3c0
  nvme_pci_map_queues+0x189/0x460 [nvme]
  blk_mq_update_nr_hw_queues+0x2a/0x40
  nvme_reset_work+0x1be/0x2a0 [nvme]

Fix the bug by locking the shutdown_lock mutex before using
dev-&gt;online_queues. Give up if nvme_dev_disable() is running or if
it has been executed already.</Note>
    </Notes>
    <CVE>CVE-2024-50135</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: bnep: fix wild-memory-access in proto_unregister

There's issue as follows:
  KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f]
  CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G        W
  RIP: 0010:proto_unregister+0xee/0x400
  Call Trace:
   &lt;TASK&gt;
   __do_sys_delete_module+0x318/0x580
   do_syscall_64+0xc1/0x1d0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f

As bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init()
will cleanup all resource. Then when remove bnep module will call
bnep_sock_cleanup() to cleanup sock's resource.
To solve above issue just return bnep_sock_init()'s return value in
bnep_exit().</Note>
    </Notes>
    <CVE>CVE-2024-50148</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: altmode should keep reference to parent

The altmode device release refers to its parent device, but without keeping
a reference to it.

When registering the altmode, get a reference to the parent and put it in
the release function.

Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues
like this:

[   43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000)
[   43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000)
[   43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000)
[   43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000)
[   43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000)
[   43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000)
[   43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000)
[   46.612867] ==================================================================
[   46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129
[   46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48
[   46.614538]
[   46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535
[   46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
[   46.616042] Workqueue: events kobject_delayed_cleanup
[   46.616446] Call Trace:
[   46.616648]  &lt;TASK&gt;
[   46.616820]  dump_stack_lvl+0x5b/0x7c
[   46.617112]  ? typec_altmode_release+0x38/0x129
[   46.617470]  print_report+0x14c/0x49e
[   46.617769]  ? rcu_read_unlock_sched+0x56/0x69
[   46.618117]  ? __virt_addr_valid+0x19a/0x1ab
[   46.618456]  ? kmem_cache_debug_flags+0xc/0x1d
[   46.618807]  ? typec_altmode_release+0x38/0x129
[   46.619161]  kasan_report+0x8d/0xb4
[   46.619447]  ? typec_altmode_release+0x38/0x129
[   46.619809]  ? process_scheduled_works+0x3cb/0x85f
[   46.620185]  typec_altmode_release+0x38/0x129
[   46.620537]  ? process_scheduled_works+0x3cb/0x85f
[   46.620907]  device_release+0xaf/0xf2
[   46.621206]  kobject_delayed_cleanup+0x13b/0x17a
[   46.621584]  process_scheduled_works+0x4f6/0x85f
[   46.621955]  ? __pfx_process_scheduled_works+0x10/0x10
[   46.622353]  ? hlock_class+0x31/0x9a
[   46.622647]  ? lock_acquired+0x361/0x3c3
[   46.622956]  ? move_linked_works+0x46/0x7d
[   46.623277]  worker_thread+0x1ce/0x291
[   46.623582]  ? __kthread_parkme+0xc8/0xdf
[   46.623900]  ? __pfx_worker_thread+0x10/0x10
[   46.624236]  kthread+0x17e/0x190
[   46.624501]  ? kthread+0xfb/0x190
[   46.624756]  ? __pfx_kthread+0x10/0x10
[   46.625015]  ret_from_fork+0x20/0x40
[   46.625268]  ? __pfx_kthread+0x10/0x10
[   46.625532]  ret_from_fork_asm+0x1a/0x30
[   46.625805]  &lt;/TASK&gt;
[   46.625953]
[   46.626056] Allocated by task 678:
[   46.626287]  kasan_save_stack+0x24/0x44
[   46.626555]  kasan_save_track+0x14/0x2d
[   46.626811]  __kasan_kmalloc+0x3f/0x4d
[   46.627049]  __kmalloc_noprof+0x1bf/0x1f0
[   46.627362]  typec_register_port+0x23/0x491
[   46.627698]  cros_typec_probe+0x634/0xbb6
[   46.628026]  platform_probe+0x47/0x8c
[   46.628311]  really_probe+0x20a/0x47d
[   46.628605]  device_driver_attach+0x39/0x72
[   46.628940]  bind_store+0x87/0xd7
[   46.629213]  kernfs_fop_write_iter+0x1aa/0x218
[   46.629574]  vfs_write+0x1d6/0x29b
[   46.629856]  ksys_write+0xcd/0x13b
[   46.630128]  do_syscall_64+0xd4/0x139
[   46.630420]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[   46.630820]
[   46.630946] Freed by task 48:
[   46.631182]  kasan_save_stack+0x24/0x44
[   46.631493]  kasan_save_track+0x14/0x2d
[   46.631799]  kasan_save_free_info+0x3f/0x4d
[   46.632144]  __kasan_slab_free+0x37/0x45
[   46.632474]
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50150</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().

Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().

  """
  We are seeing a use-after-free from a bpf prog attached to
  trace_tcp_retransmit_synack. The program passes the req-&gt;sk to the
  bpf_sk_storage_get_tracing kernel helper which does check for null
  before using it.
  """

The commit 83fccfc3940c ("inet: fix potential deadlock in
reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not
to call del_timer_sync() from reqsk_timer_handler(), but it introduced a
small race window.

Before the timer is called, expire_timers() calls detach_timer(timer, true)
to clear timer-&gt;entry.pprev and marks it as not pending.

If reqsk_queue_unlink() checks timer_pending() just after expire_timers()
calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will
continue running and send multiple SYN+ACKs until it expires.

The reported UAF could happen if req-&gt;sk is close()d earlier than the timer
expiration, which is 63s by default.

The scenario would be

  1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),
     but del_timer_sync() is missed

  2. reqsk timer is executed and scheduled again

  3. req-&gt;sk is accept()ed and reqsk_put() decrements rsk_refcnt, but
     reqsk timer still has another one, and inet_csk_accept() does not
     clear req-&gt;sk for non-TFO sockets

  4. sk is close()d

  5. reqsk timer is executed again, and BPF touches req-&gt;sk

Let's not use timer_pending() by passing the caller context to
__inet_csk_reqsk_queue_drop().

Note that reqsk timer is pinned, so the issue does not happen in most
use cases. [1]

[0]
BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0

Use-after-free read at 0x00000000a891fb3a (in kfence-#1):
bpf_sk_storage_get_tracing+0x2e/0x1b0
bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda
bpf_trace_run2+0x4c/0xc0
tcp_rtx_synack+0xf9/0x100
reqsk_timer_handler+0xda/0x3d0
run_timer_softirq+0x292/0x8a0
irq_exit_rcu+0xf5/0x320
sysvec_apic_timer_interrupt+0x6d/0x80
asm_sysvec_apic_timer_interrupt+0x16/0x20
intel_idle_irq+0x5a/0xa0
cpuidle_enter_state+0x94/0x273
cpu_startup_entry+0x15e/0x260
start_secondary+0x8a/0x90
secondary_startup_64_no_verify+0xfa/0xfb

kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6

allocated by task 0 on cpu 9 at 260507.901592s:
sk_prot_alloc+0x35/0x140
sk_clone_lock+0x1f/0x3f0
inet_csk_clone_lock+0x15/0x160
tcp_create_openreq_child+0x1f/0x410
tcp_v6_syn_recv_sock+0x1da/0x700
tcp_check_req+0x1fb/0x510
tcp_v6_rcv+0x98b/0x1420
ipv6_list_rcv+0x2258/0x26e0
napi_complete_done+0x5b1/0x2990
mlx5e_napi_poll+0x2ae/0x8d0
net_rx_action+0x13e/0x590
irq_exit_rcu+0xf5/0x320
common_interrupt+0x80/0x90
asm_common_interrupt+0x22/0x40
cpuidle_enter_state+0xfb/0x273
cpu_startup_entry+0x15e/0x260
start_secondary+0x8a/0x90
secondary_startup_64_no_verify+0xfa/0xfb

freed by task 0 on cpu 9 at 260507.927527s:
rcu_core_si+0x4ff/0xf10
irq_exit_rcu+0xf5/0x320
sysvec_apic_timer_interrupt+0x6d/0x80
asm_sysvec_apic_timer_interrupt+0x16/0x20
cpuidle_enter_state+0xfb/0x273
cpu_startup_entry+0x15e/0x260
start_secondary+0x8a/0x90
secondary_startup_64_no_verify+0xfa/0xfb</Note>
    </Notes>
    <CVE>CVE-2024-50154</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

be2net: fix potential memory leak in be_xmit()

The be_xmit() returns NETDEV_TX_OK without freeing skb
in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.</Note>
    </Notes>
    <CVE>CVE-2024-50167</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: systemport: fix potential memory leak in bcm_sysport_xmit()

The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb
in case of dma_map_single() fails, add dev_kfree_skb() to fix it.</Note>
    </Notes>
    <CVE>CVE-2024-50171</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ceph: remove the incorrect Fw reference check when dirtying pages

When doing the direct-io reads it will also try to mark pages dirty,
but for the read path it won't hold the Fw caps and there is case
will it get the Fw reference.</Note>
    </Notes>
    <CVE>CVE-2024-50179</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Ensure DA_ID handling completion before deleting an NPIV instance

Deleting an NPIV instance requires all fabric ndlps to be released before
an NPIV's resources can be torn down.  Failure to release fabric ndlps
beforehand opens kref imbalance race conditions.  Fix by forcing the DA_ID
to complete synchronously with usage of wait_queue.</Note>
    </Notes>
    <CVE>CVE-2024-50183</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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/vc4: Stop the active perfmon before being destroyed

Upon closing the file descriptor, the active performance monitor is not
stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`,
the active performance monitor's pointer (`vc4-&gt;active_perfmon`) is still
retained.

If we open a new file descriptor and submit a few jobs with performance
monitors, the driver will attempt to stop the active performance monitor
using the stale pointer in `vc4-&gt;active_perfmon`. However, this pointer
is no longer valid because the previous process has already terminated,
and all performance monitors associated with it have been destroyed and
freed.

To fix this, when the active performance monitor belongs to a given
process, explicitly stop it before destroying and freeing it.</Note>
    </Notes>
    <CVE>CVE-2024-50187</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: probes: Fix uprobes for big-endian kernels

The arm64 uprobes code is broken for big-endian kernels as it doesn't
convert the in-memory instruction encoding (which is always
little-endian) into the kernel's native endianness before analyzing and
simulating instructions. This may result in a few distinct problems:

* The kernel may may erroneously reject probing an instruction which can
  safely be probed.

* The kernel may erroneously erroneously permit stepping an
  instruction out-of-line when that instruction cannot be stepped
  out-of-line safely.

* The kernel may erroneously simulate instruction incorrectly dur to
  interpretting the byte-swapped encoding.

The endianness mismatch isn't caught by the compiler or sparse because:

* The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so
  the compiler and sparse have no idea these contain a little-endian
  32-bit value. The core uprobes code populates these with a memcpy()
  which similarly does not handle endianness.

* While the uprobe_opcode_t type is an alias for __le32, both
  arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]
  to the similarly-named probe_opcode_t, which is an alias for u32.
  Hence there is no endianness conversion warning.

Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and
adding the appropriate __le32_to_cpu() conversions prior to consuming
the instruction encoding. The core uprobes copies these fields as opaque
ranges of bytes, and so is unaffected by this change.

At the same time, remove MAX_UINSN_BYTES and consistently use
AARCH64_INSN_SIZE for clarity.

Tested with the following:

| #include &lt;stdio.h&gt;
| #include &lt;stdbool.h&gt;
|
| #define noinline __attribute__((noinline))
|
| static noinline void *adrp_self(void)
| {
|         void *addr;
|
|         asm volatile(
|         "       adrp    %x0, adrp_self\n"
|         "       add     %x0, %x0, :lo12:adrp_self\n"
|         : "=r" (addr));
| }
|
|
| int main(int argc, char *argv)
| {
|         void *ptr = adrp_self();
|         bool equal = (ptr == adrp_self);
|
|         printf("adrp_self   =&gt; %p\n"
|                "adrp_self() =&gt; %p\n"
|                "%s\n",
|                adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL");
|
|         return 0;
| }

.... where the adrp_self() function was compiled to:

| 00000000004007e0 &lt;adrp_self&gt;:
|   4007e0:       90000000        adrp    x0, 400000 &lt;__ehdr_start&gt;
|   4007e4:       911f8000        add     x0, x0, #0x7e0
|   4007e8:       d65f03c0        ret

Before this patch, the ADRP is not recognized, and is assumed to be
steppable, resulting in corruption of the result:

| # ./adrp-self
| adrp_self   =&gt; 0x4007e0
| adrp_self() =&gt; 0x4007e0
| EQUAL
| # echo 'p /root/adrp-self:0x007e0' &gt; /sys/kernel/tracing/uprobe_events
| # echo 1 &gt; /sys/kernel/tracing/events/uprobes/enable
| # ./adrp-self
| adrp_self   =&gt; 0x4007e0
| adrp_self() =&gt; 0xffffffffff7e0
| NOT EQUAL

After this patch, the ADRP is correctly recognized and simulated:

| # ./adrp-self
| adrp_self   =&gt; 0x4007e0
| adrp_self() =&gt; 0x4007e0
| EQUAL
| #
| # echo 'p /root/adrp-self:0x007e0' &gt; /sys/kernel/tracing/uprobe_events
| # echo 1 &gt; /sys/kernel/tracing/events/uprobes/enable
| # ./adrp-self
| adrp_self   =&gt; 0x4007e0
| adrp_self() =&gt; 0x4007e0
| EQUAL</Note>
    </Notes>
    <CVE>CVE-2024-50194</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

posix-clock: Fix missing timespec64 check in pc_clock_settime()

As Andrew pointed out, it will make sense that the PTP core
checked timespec64 struct's tv_sec and tv_nsec range before calling
ptp-&gt;info-&gt;settime64().

As the man manual of clock_settime() said, if tp.tv_sec is negative or
tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,
which include dynamic clocks which handles PTP clock, and the condition is
consistent with timespec64_valid(). As Thomas suggested, timespec64_valid()
only check the timespec is valid, but not ensure that the time is
in a valid range, so check it ahead using timespec64_valid_strict()
in pc_clock_settime() and return -EINVAL if not valid.

There are some drivers that use tp-&gt;tv_sec and tp-&gt;tv_nsec directly to
write registers without validity checks and assume that the higher layer
has checked it, which is dangerous and will benefit from this, such as
hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),
and some drivers can remove the checks of itself.</Note>
    </Notes>
    <CVE>CVE-2024-50195</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow

Syzbot reported a kernel BUG in ocfs2_truncate_inline.  There are two
reasons for this: first, the parameter value passed is greater than
ocfs2_max_inline_data_with_xattr, second, the start and end parameters of
ocfs2_truncate_inline are "unsigned int".

So, we need to add a sanity check for byte_start and byte_len right before
ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater
than ocfs2_max_inline_data_with_xattr return -EINVAL.</Note>
    </Notes>
    <CVE>CVE-2024-50218</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2024-50228</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: iwlegacy: Clear stale interrupts before resuming device

iwl4965 fails upon resume from hibernation on my laptop. The reason
seems to be a stale interrupt which isn't being cleared out before
interrupts are enabled. We end up with a race beween the resume
trying to bring things back up, and the restart work (queued form
the interrupt handler) trying to bring things down. Eventually
the whole thing blows up.

Fix the problem by clearing out any stale interrupts before
interrupts get enabled during resume.

Here's a debug log of the indicent:
[   12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000
[   12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000
[   12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio.
[   12.042653] iwl4965 0000:10:00.0: On demand firmware reload
[   12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282
[   12.052207] ieee80211 phy0: il4965_mac_start enter
[   12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff
[   12.052244] ieee80211 phy0: il4965_set_hw_ready hardware  ready
[   12.052324] ieee80211 phy0: il_apm_init Init card's basic functions
[   12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S
[   12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm
[   12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm
[   12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK
[   12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations
[   12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up
[   12.058737] ieee80211 phy0: il4965_mac_start Start UP work done.
[   12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down
[   12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout
[   12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort
[   12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver
[   12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared
[   12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state
[   12.058827] ieee80211 phy0: _il_apm_stop_master stop master
[   12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear.
[   12.058869] ieee80211 phy0: Hardware restart was requested
[   16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms.
[   16.132303] ------------[ cut here ]------------
[   16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.
[   16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211]
[   16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev
[   16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143
[   16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010
[   16.132463] Workqueue: async async_run_entry_fn
[   16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211]
[   16.132501] Code: da 02 00 0
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-50234</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ath10k: Fix memory leak in management tx

In the current logic, memory is allocated for storing the MSDU context
during management packet TX but this memory is not being freed during
management TX completion. Similar leaks are seen in the management TX
cleanup logic.

Kmemleak reports this problem as below,

unreferenced object 0xffffff80b64ed250 (size 16):
  comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s)
  hex dump (first 16 bytes):
    00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00  .+.......t......
  backtrace:
    [&lt;ffffffe6e7b245dc&gt;] __kmem_cache_alloc_node+0x1e4/0x2d8
    [&lt;ffffffe6e7adde88&gt;] kmalloc_trace+0x48/0x110
    [&lt;ffffffe6bbd765fc&gt;] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core]
    [&lt;ffffffe6bbd3eed4&gt;] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core]
    [&lt;ffffffe6e78d5974&gt;] process_scheduled_works+0x1ac/0x400
    [&lt;ffffffe6e78d60b8&gt;] worker_thread+0x208/0x328
    [&lt;ffffffe6e78dc890&gt;] kthread+0x100/0x1c0
    [&lt;ffffffe6e78166c0&gt;] ret_from_fork+0x10/0x20

Free the memory during completion and cleanup to fix the leak.

Protect the mgmt_pending_tx idr_remove() operation in
ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar-&gt;data_lock similar to
other instances.

Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1</Note>
    </Notes>
    <CVE>CVE-2024-50236</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: do not pass a stopped vif to the driver in .get_txpower

Avoid potentially crashing in the driver because of uninitialized private data</Note>
    </Notes>
    <CVE>CVE-2024-50237</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: Initialization of the dangling pointer occurring in vsk-&gt;trans

During loopback communication, a dangling pointer can be created in
vsk-&gt;trans, potentially leading to a Use-After-Free condition.  This
issue is resolved by initializing vsk-&gt;trans to NULL.</Note>
    </Notes>
    <CVE>CVE-2024-50264</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()

Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():

[   57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12
[   57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper.  Leaking 1 clusters and removing the entry
[   57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004
[...]
[   57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0
[...]
[   57.331328] Call Trace:
[   57.331477]  &lt;TASK&gt;
[...]
[   57.333511]  ? do_user_addr_fault+0x3e5/0x740
[   57.333778]  ? exc_page_fault+0x70/0x170
[   57.334016]  ? asm_exc_page_fault+0x2b/0x30
[   57.334263]  ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10
[   57.334596]  ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0
[   57.334913]  ocfs2_xa_remove_entry+0x23/0xc0
[   57.335164]  ocfs2_xa_set+0x704/0xcf0
[   57.335381]  ? _raw_spin_unlock+0x1a/0x40
[   57.335620]  ? ocfs2_inode_cache_unlock+0x16/0x20
[   57.335915]  ? trace_preempt_on+0x1e/0x70
[   57.336153]  ? start_this_handle+0x16c/0x500
[   57.336410]  ? preempt_count_sub+0x50/0x80
[   57.336656]  ? _raw_read_unlock+0x20/0x40
[   57.336906]  ? start_this_handle+0x16c/0x500
[   57.337162]  ocfs2_xattr_block_set+0xa6/0x1e0
[   57.337424]  __ocfs2_xattr_set_handle+0x1fd/0x5d0
[   57.337706]  ? ocfs2_start_trans+0x13d/0x290
[   57.337971]  ocfs2_xattr_set+0xb13/0xfb0
[   57.338207]  ? dput+0x46/0x1c0
[   57.338393]  ocfs2_xattr_trusted_set+0x28/0x30
[   57.338665]  ? ocfs2_xattr_trusted_set+0x28/0x30
[   57.338948]  __vfs_removexattr+0x92/0xc0
[   57.339182]  __vfs_removexattr_locked+0xd5/0x190
[   57.339456]  ? preempt_count_sub+0x50/0x80
[   57.339705]  vfs_removexattr+0x5f/0x100
[...]

Reproducer uses faultinject facility to fail ocfs2_xa_remove() -&gt;
ocfs2_xa_value_truncate() with -ENOMEM.

In this case the comment mentions that we can return 0 if
ocfs2_xa_cleanup_value_truncate() is going to wipe the entry
anyway. But the following 'rc' check is wrong and execution flow do
'ocfs2_xa_remove_entry(loc);' twice:
* 1st: in ocfs2_xa_cleanup_value_truncate();
* 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'.

Fix this by skipping the 2nd removal of the same entry and making
syzkaller repro happy.</Note>
    </Notes>
    <CVE>CVE-2024-50265</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

USB: serial: io_edgeport: fix use after free in debug printk

The "dev_dbg(&amp;urb-&gt;dev-&gt;dev, ..." which happens after usb_free_urb(urb)
is a use after free of the "urb" pointer.  Store the "dev" pointer at the
start of the function to avoid this issue.</Note>
    </Notes>
    <CVE>CVE-2024-50267</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

btrfs: reinitialize delayed ref list after deleting it from the list

At insert_delayed_ref() if we need to update the action of an existing
ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's
ref_add_list using list_del(), which leaves the ref's add_list member
not reinitialized, as list_del() sets the next and prev members of the
list to LIST_POISON1 and LIST_POISON2, respectively.

If later we end up calling drop_delayed_ref() against the ref, which can
happen during merging or when destroying delayed refs due to a transaction
abort, we can trigger a crash since at drop_delayed_ref() we call
list_empty() against the ref's add_list, which returns false since
the list was not reinitialized after the list_del() and as a consequence
we call list_del() again at drop_delayed_ref(). This results in an
invalid list access since the next and prev members are set to poison
pointers, resulting in a splat if CONFIG_LIST_HARDENED and
CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences
otherwise.

So fix this by deleting from the list with list_del_init() instead.</Note>
    </Notes>
    <CVE>CVE-2024-50273</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dm cache: fix potential out-of-bounds access on the first resume

Out-of-bounds access occurs if the fast device is expanded unexpectedly
before the first-time resume of the cache table. This happens because
expanding the fast device requires reloading the cache table for
cache_create to allocate new in-core data structures that fit the new
size, and the check in cache_preresume is not performed during the
first resume, leading to the issue.

Reproduce steps:

1. prepare component devices:

dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"
dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"
dmsetup create corig --table "0 524288 linear /dev/sdc 262144"
dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct

2. load a cache table of 512 cache blocks, and deliberately expand the
   fast device before resuming the cache, making the in-core data
   structures inadequate.

dmsetup create cache --notable
dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \
/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192"
dmsetup resume cdata
dmsetup resume cache

3. suspend the cache to write out the in-core dirty bitset and hint
   array, leading to out-of-bounds access to the dirty bitset at offset
   0x40:

dmsetup suspend cache

KASAN reports:

  BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80
  Read of size 8 at addr ffffc90000085040 by task dmsetup/90

  (...snip...)
  The buggy address belongs to the virtual mapping at
   [ffffc90000085000, ffffc90000087000) created by:
   cache_ctr+0x176a/0x35f0

  (...snip...)
  Memory state around the buggy address:
   ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
   ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
  &gt;ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8
                                             ^
   ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
   ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8

Fix by checking the size change on the first resume.</Note>
    </Notes>
    <CVE>CVE-2024-50278</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dm cache: fix out-of-bounds access to the dirty bitset when resizing

dm-cache checks the dirty bits of the cache blocks to be dropped when
shrinking the fast device, but an index bug in bitset iteration causes
out-of-bounds access.

Reproduce steps:

1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)

dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"
dmsetup create cdata --table "0 131072 linear /dev/sdc 8192"
dmsetup create corig --table "0 524288 linear /dev/sdc 262144"
dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct
dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \
/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"

2. shrink the fast device to 512 cache blocks, triggering out-of-bounds
   access to the dirty bitset (offset 0x80)

dmsetup suspend cache
dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192"
dmsetup resume cdata
dmsetup resume cache

KASAN reports:

  BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0
  Read of size 8 at addr ffffc900000f3080 by task dmsetup/131

  (...snip...)
  The buggy address belongs to the virtual mapping at
   [ffffc900000f3000, ffffc900000f5000) created by:
   cache_ctr+0x176a/0x35f0

  (...snip...)
  Memory state around the buggy address:
   ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
   ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  &gt;ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
                     ^
   ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
   ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8

Fix by making the index post-incremented.</Note>
    </Notes>
    <CVE>CVE-2024-50279</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: av7110: fix a spectre vulnerability

As warned by smatch:
	drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110-&gt;ci_slot' [w] (local cap)

There is a spectre-related vulnerability at the code. Fix it.</Note>
    </Notes>
    <CVE>CVE-2024-50289</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: cx24116: prevent overflows on SNR calculus

as reported by Coverity, if reading SNR registers fail, a negative
number will be returned, causing an underflow when reading SNR
registers.

Prevent that.</Note>
    </Notes>
    <CVE>CVE-2024-50290</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: hns3: fix kernel crash when uninstalling driver

When the driver is uninstalled and the VF is disabled concurrently, a
kernel crash occurs. The reason is that the two actions call function
pci_disable_sriov(). The num_VFs is checked to determine whether to
release the corresponding resources. During the second calling, num_VFs
is not 0 and the resource release function is called. However, the
corresponding resource has been released during the first invoking.
Therefore, the problem occurs:

[15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
...
[15278.131557][T50670] Call trace:
[15278.134686][T50670]  klist_put+0x28/0x12c
[15278.138682][T50670]  klist_del+0x14/0x20
[15278.142592][T50670]  device_del+0xbc/0x3c0
[15278.146676][T50670]  pci_remove_bus_device+0x84/0x120
[15278.151714][T50670]  pci_stop_and_remove_bus_device+0x6c/0x80
[15278.157447][T50670]  pci_iov_remove_virtfn+0xb4/0x12c
[15278.162485][T50670]  sriov_disable+0x50/0x11c
[15278.166829][T50670]  pci_disable_sriov+0x24/0x30
[15278.171433][T50670]  hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3]
[15278.178039][T50670]  hclge_exit+0x28/0xd0 [hclge]
[15278.182730][T50670]  __se_sys_delete_module.isra.0+0x164/0x230
[15278.188550][T50670]  __arm64_sys_delete_module+0x1c/0x30
[15278.193848][T50670]  invoke_syscall+0x50/0x11c
[15278.198278][T50670]  el0_svc_common.constprop.0+0x158/0x164
[15278.203837][T50670]  do_el0_svc+0x34/0xcc
[15278.207834][T50670]  el0_svc+0x20/0x30

For details, see the following figure.

     rmmod hclge              disable VFs
----------------------------------------------------
hclge_exit()            sriov_numvfs_store()
  ...                     device_lock()
  pci_disable_sriov()     hns3_pci_sriov_configure()
                            pci_disable_sriov()
                              sriov_disable()
    sriov_disable()             if !num_VFs :
      if !num_VFs :               return;
        return;                 sriov_del_vfs()
      sriov_del_vfs()             ...
        ...                       klist_put()
        klist_put()               ...
        ...                     num_VFs = 0;
      num_VFs = 0;        device_unlock();

In this patch, when driver is removing, we get the device_lock()
to protect num_VFs, just like sriov_numvfs_store().</Note>
    </Notes>
    <CVE>CVE-2024-50296</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

security/keys: fix slab-out-of-bounds in key_task_permission

KASAN reports an out of bounds read:
BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36
BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline]
BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410
security/keys/permission.c:54
Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362

CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15
Call Trace:
 __dump_stack lib/dump_stack.c:82 [inline]
 dump_stack+0x107/0x167 lib/dump_stack.c:123
 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400
 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560
 kasan_report+0x3a/0x50 mm/kasan/report.c:585
 __kuid_val include/linux/uidgid.h:36 [inline]
 uid_eq include/linux/uidgid.h:63 [inline]
 key_task_permission+0x394/0x410 security/keys/permission.c:54
 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793

This issue was also reported by syzbot.

It can be reproduced by following these steps(more details [1]):
1. Obtain more than 32 inputs that have similar hashes, which ends with the
   pattern '0xxxxxxxe6'.
2. Reboot and add the keys obtained in step 1.

The reproducer demonstrates how this issue happened:
1. In the search_nested_keyrings function, when it iterates through the
   slots in a node(below tag ascend_to_node), if the slot pointer is meta
   and node-&gt;back_pointer != NULL(it means a root), it will proceed to
   descend_to_node. However, there is an exception. If node is the root,
   and one of the slots points to a shortcut, it will be treated as a
   keyring.
2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function.
   However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as
   ASSOC_ARRAY_PTR_SUBTYPE_MASK.
3. When 32 keys with the similar hashes are added to the tree, the ROOT
   has keys with hashes that are not similar (e.g. slot 0) and it splits
   NODE A without using a shortcut. When NODE A is filled with keys that
   all hashes are xxe6, the keys are similar, NODE A will split with a
   shortcut. Finally, it forms the tree as shown below, where slot 6 points
   to a shortcut.

                      NODE A
              +------&gt;+---+
      ROOT    |       | 0 | xxe6
      +---+   |       +---+
 xxxx | 0 | shortcut  :   : xxe6
      +---+   |       +---+
 xxe6 :   :   |       |   | xxe6
      +---+   |       +---+
      | 6 |---+       :   : xxe6
      +---+           +---+
 xxe6 :   :           | f | xxe6
      +---+           +---+
 xxe6 | f |
      +---+

4. As mentioned above, If a slot(slot 6) of the root points to a shortcut,
   it may be mistakenly transferred to a key*, leading to a read
   out-of-bounds read.

To fix this issue, one should jump to descend_to_node if the ptr is a
shortcut, regardless of whether the node is root or not.

[1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/

[jarkko: tweaked the commit message a bit to have an appropriate closes
 tag.]</Note>
    </Notes>
    <CVE>CVE-2024-50301</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

HID: core: zero-initialize the report buffer

Since the report buffer is used by all kinds of drivers in various ways, let's
zero-initialize it during allocation to make sure that it can't be ever used
to leak kernel memory via specially-crafted report.</Note>
    </Notes>
    <CVE>CVE-2024-50302</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was discovered in libexpat before 2.6.4. There is a crash within the XML_ResumeParser function because XML_StopParser can stop/suspend an unstarted parser.</Note>
    </Notes>
    <CVE>CVE-2024-50602</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:expat-2.1.0-21.40.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libexpat1-2.1.0-21.40.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">gio/gsocks4aproxy.c in GNOME GLib before 2.82.1 has an off-by-one error and resultant buffer overflow because SOCKS4_CONN_MSG_LEN is not sufficient for a trailing '\0' character.</Note>
    </Notes>
    <CVE>CVE-2024-52533</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:glib2-tools-2.48.2-12.43.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libgio-2_0-0-2.48.2-12.43.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libglib-2_0-0-2.48.2-12.43.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libgmodule-2_0-0-2.48.2-12.43.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libgobject-2_0-0-2.48.2-12.43.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in the Avahi-daemon, where it initializes DNS transaction IDs randomly only once at startup, incrementing them sequentially after that. This predictable behavior facilitates DNS spoofing attacks, allowing attackers to guess transaction IDs.</Note>
    </Notes>
    <CVE>CVE-2024-52616</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libavahi-client3-0.6.32-32.30.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libavahi-common3-0.6.32-32.30.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.</Note>
    </Notes>
    <CVE>CVE-2024-53058</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.</Note>
    </Notes>
    <CVE>CVE-2024-53061</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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">** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.</Note>
    </Notes>
    <CVE>CVE-2024-53063</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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">** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.</Note>
    </Notes>
    <CVE>CVE-2024-53066</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tpm: Lock TPM chip in tpm_pm_suspend() first

Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy
according, as this leaves window for tpm_hwrng_read() to be called while
the operation is in progress. The recent bug report gives also evidence of
this behaviour.

Aadress this by locking the TPM chip before checking any chip-&gt;flags both
in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED
check inside tpm_get_random() so that it will be always checked only when
the lock is reserved.</Note>
    </Notes>
    <CVE>CVE-2024-53085</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 race condition by adding filter's intermediate sync state

Fix a race condition in the i40e driver that leads to MAC/VLAN filters
becoming corrupted and leaking. Address the issue that occurs under
heavy load when multiple threads are concurrently modifying MAC/VLAN
filters by setting mac and port VLAN.

1. Thread T0 allocates a filter in i40e_add_filter() within
        i40e_ndo_set_vf_port_vlan().
2. Thread T1 concurrently frees the filter in __i40e_del_filter() within
        i40e_ndo_set_vf_mac().
3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which
        refers to the already freed filter memory, causing corruption.

Reproduction steps:
1. Spawn multiple VFs.
2. Apply a concurrent heavy load by running parallel operations to change
        MAC addresses on the VFs and change port VLANs on the host.
3. Observe errors in dmesg:
"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX,
	please set promiscuous on manually for VF XX".

Exact code for stable reproduction Intel can't open-source now.

The fix involves implementing a new intermediate filter state,
I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list.
These filters cannot be deleted from the hash list directly but
must be removed using the full process.</Note>
    </Notes>
    <CVE>CVE-2024-53088</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format

This can lead to out of bounds writes since frames of this type were not
taken into account when calculating the size of the frames buffer in
uvc_parse_streaming.</Note>
    </Notes>
    <CVE>CVE-2024-53104</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.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:

x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client

A number of Zen4 client SoCs advertise the ability to use virtualized
VMLOAD/VMSAVE, but using these instructions is reported to be a cause
of a random host reboot.

These instructions aren't intended to be advertised on Zen4 client
so clear the capability.</Note>
    </Notes>
    <CVE>CVE-2024-53114</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

initramfs: avoid filename buffer overrun

The initramfs filename field is defined in
Documentation/driver-api/early-userspace/buffer-format.rst as:

 37 cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data
...
 55 ============= ================== =========================
 56 Field name    Field size         Meaning
 57 ============= ================== =========================
...
 70 c_namesize    8 bytes            Length of filename, including final \0

When extracting an initramfs cpio archive, the kernel's do_name() path
handler assumes a zero-terminated path at @collected, passing it
directly to filp_open() / init_mkdir() / init_mknod().

If a specially crafted cpio entry carries a non-zero-terminated filename
and is followed by uninitialized memory, then a file may be created with
trailing characters that represent the uninitialized memory. The ability
to create an initramfs entry would imply already having full control of
the system, so the buffer overrun shouldn't be considered a security
vulnerability.

Append the output of the following bash script to an existing initramfs
and observe any created /initramfs_test_fname_overrunAA* path. E.g.
  ./reproducer.sh | gzip &gt;&gt; /myinitramfs

It's easiest to observe non-zero uninitialized memory when the output is
gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(),
rather than the initrd_start+initrd_size block.

---- reproducer.sh ----
nilchar="A"	# change to "\0" to properly zero terminate / pad
magic="070701"
ino=1
mode=$(( 0100777 ))
uid=0
gid=0
nlink=1
mtime=1
filesize=0
devmajor=0
devminor=1
rdevmajor=0
rdevminor=0
csum=0
fname="initramfs_test_fname_overrun"
namelen=$(( ${#fname} + 1 ))	# plus one to account for terminator

printf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \
	$magic $ino $mode $uid $gid $nlink $mtime $filesize \
	$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname

termpadlen=$(( 1 + ((4 - ((110 + $namelen) &amp; 3)) % 4) ))
printf "%.s${nilchar}" $(seq 1 $termpadlen)
---- reproducer.sh ----

Symlink filename fields handled in do_symlink() won't overrun past the
data segment, due to the explicit zero-termination of the symlink
target.

Fix filename buffer overrun by aborting the initramfs FSM if any cpio
entry doesn't carry a zero-terminator at the expected (name_len - 1)
offset.</Note>
    </Notes>
    <CVE>CVE-2024-53142</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:kernel-default-4.12.14-122.237.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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: Calling the OpenSSL API function SSL_select_next_proto with an
empty supported client protocols buffer may cause a crash or memory contents to
be sent to the peer.

Impact summary: A buffer overread can have a range of potential consequences
such as unexpected application beahviour or a crash. In particular this issue
could result in up to 255 bytes of arbitrary private data from memory being sent
to the peer leading to a loss of confidentiality. However, only applications
that directly call the SSL_select_next_proto function with a 0 length list of
supported client protocols are affected by this issue. This would normally never
be a valid scenario and is typically not under attacker control but may occur by
accident in the case of a configuration or programming error in the calling
application.

The OpenSSL API function SSL_select_next_proto is typically used by TLS
applications that support ALPN (Application Layer Protocol Negotiation) or NPN
(Next Protocol Negotiation). NPN is older, was never standardised and
is deprecated in favour of ALPN. We believe that ALPN is significantly more
widely deployed than NPN. The SSL_select_next_proto function accepts a list of
protocols from the server and a list of protocols from the client and returns
the first protocol that appears in the server list that also appears in the
client list. In the case of no overlap between the two lists it returns the
first item in the client list. In either case it will signal whether an overlap
between the two lists was found. In the case where SSL_select_next_proto is
called with a zero length client list it fails to notice this condition and
returns the memory immediately following the client list pointer (and reports
that there was no overlap in the lists).

This function is typically called from a server side application callback for
ALPN or a client side application callback for NPN. In the case of ALPN the list
of protocols supplied by the client is guaranteed by libssl to never be zero in
length. The list of server protocols comes from the application and should never
normally be expected to be of zero length. In this case if the
SSL_select_next_proto function has been called as expected (with the list
supplied by the client passed in the client/client_len parameters), then the
application will not be vulnerable to this issue. If the application has
accidentally been configured with a zero length server list, and has
accidentally passed that zero length server list in the client/client_len
parameters, and has additionally failed to correctly handle a "no overlap"
response (which would normally result in a handshake failure in ALPN) then it
will be vulnerable to this problem.

In the case of NPN, the protocol permits the client to opportunistically select
a protocol when there is no overlap. OpenSSL returns the first client protocol
in the no overlap case in support of this. The list of client protocols comes
from the application and should never normally be expected to be of zero length.
However if the SSL_select_next_proto function is accidentally called with a
client_len of 0 then an invalid memory pointer will be returned instead. If the
application uses this output as the opportunistic protocol then the loss of
confidentiality will occur.

This issue has been assessed as Low severity because applications are most
likely to be vulnerable if they are using NPN instead of ALPN - but NPN is not
widely used. It also requires an application configuration or programming error.
Finally, this issue would not typically be under attacker control making active
exploitation unlikely.

The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

Due to the low severity of this issue we are not issuing new releases of
OpenSSL at this time. The fix will be included in the next releases when they
become available.</Note>
    </Notes>
    <CVE>CVE-2024-5535</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libopenssl1_0_0-1.0.2p-3.95.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libopenssl1_1-1.1.1d-2.113.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:openssl-1_0_0-1.0.2p-3.95.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">CPython 3.9 and earlier doesn't disallow configuring an empty list ("[]") for SSLContext.set_npn_protocols() which is an invalid value for the underlying OpenSSL API. This results in a buffer over-read when NPN is used (see CVE-2024-5535 for OpenSSL). This vulnerability is of low severity due to NPN being not widely used and specifying an empty list likely being uncommon in-practice (typically a protocol name would be configured).</Note>
    </Notes>
    <CVE>CVE-2024-5642</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">There is a MEDIUM severity vulnerability affecting CPython.





Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.</Note>
    </Notes>
    <CVE>CVE-2024-6232</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libpython3_4m1_0-3.4.10-25.145.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-3.4.10-25.145.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-base-3.4.10-25.145.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability in the package_index module of pypa/setuptools versions up to 69.1.1 allows for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. The issue is fixed in version 70.0.</Note>
    </Notes>
    <CVE>CVE-2024-6345</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-setuptools-40.6.2-4.24.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">There is a MEDIUM severity vulnerability affecting CPython.

The 
email module didn't properly quote newlines for email headers when 
serializing an email message allowing for header injection when an email
 is serialized.</Note>
    </Notes>
    <CVE>CVE-2024-6923</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libpython3_4m1_0-3.4.10-25.145.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-3.4.10-25.145.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-base-3.4.10-25.145.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">libcurl's ASN1 parser code has the `GTime2str()` function, used for parsing an
ASN.1 Generalized Time field. If given an syntactically incorrect field, the
parser might end up using -1 for the length of the *time fraction*, leading to
a `strlen()` getting performed on a pointer to a heap buffer area that is not
(purposely) null terminated.

This flaw most likely leads to a crash, but can also lead to heap contents
getting returned to the application when
[CURLINFO_CERTINFO](https://curl.se/libcurl/c/CURLINFO_CERTINFO.html) is used.</Note>
    </Notes>
    <CVE>CVE-2024-7264</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:curl-8.0.1-11.101.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libcurl4-8.0.1-11.101.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">There is a LOW severity vulnerability affecting CPython, specifically the
'http.cookies' standard library module.


When parsing cookies that contained backslashes for quoted characters in
the cookie value, the parser would use an algorithm with quadratic
complexity, resulting in excess CPU resources being used while parsing the
value.</Note>
    </Notes>
    <CVE>CVE-2024-7592</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libpython3_4m1_0-3.4.10-25.145.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-3.4.10-25.145.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-base-3.4.10-25.145.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Remote packet capture support is disabled by default in libpcap.  When a user builds libpcap with remote packet capture support enabled, one of the functions that become available is pcap_findalldevs_ex().  One of the function arguments can be a filesystem path, which normally means a directory with input data files.  When the specified path cannot be used as a directory, the function receives NULL from opendir(), but does not check the return value and passes the NULL value to readdir(), which causes a NULL pointer derefence.</Note>
    </Notes>
    <CVE>CVE-2024-8006</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libpcap1-1.8.1-10.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">When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine.  If the returned status reports another error than 'revoked' (like for example 'unauthorized') it is not treated as a bad certficate.</Note>
    </Notes>
    <CVE>CVE-2024-8096</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:curl-8.0.1-11.101.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libcurl4-8.0.1-11.101.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability has been found in the CPython `venv` module and CLI where path names provided when creating a virtual environment were not quoted properly, allowing the creator to inject commands into virtual environment "activation" scripts (ie "source venv/bin/activate"). This means that attacker-controlled virtual environments are able to run commands when the virtual environment is activated. Virtual environments which are not created by an attacker or which aren't activated before being used (ie "./venv/bin/python") are not affected.</Note>
    </Notes>
    <CVE>CVE-2024-9287</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libpython3_4m1_0-3.4.10-25.145.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-3.4.10-25.145.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:python3-base-3.4.10-25.145.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When curl is asked to use HSTS, the expiry time for a subdomain might
overwrite a parent domain's cache entry, making it end sooner or later than
otherwise intended.

This affects curl using applications that enable HSTS and use URLs with the
insecure `HTTP://` scheme and perform transfers with hosts like
`x.example.com` as well as `example.com` where the first host is a subdomain
of the second host.

(The HSTS cache either needs to have been populated manually or there needs to
have been previous HTTPS accesses done as the cache needs to have entries for
the domains involved to trigger this problem.)

When `x.example.com` responds with `Strict-Transport-Security:` headers, this
bug can make the subdomain's expiry timeout *bleed over* and get set for the
parent domain `example.com` in curl's HSTS cache.

The result of a triggered bug is that HTTP accesses to `example.com` get
converted to HTTPS for a different period of time than what was asked for by
the origin server. If `example.com` for example stops supporting HTTPS at its
expiry time, curl might then fail to access `http://example.com` until the
(wrongly set) timeout expires. This bug can also expire the parent's entry
*earlier*, thus making curl inadvertently switch back to insecure HTTP earlier
than otherwise intended.</Note>
    </Notes>
    <CVE>CVE-2024-9681</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:curl-8.0.1-11.101.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-v20250103-x86-64:libcurl4-8.0.1-11.101.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
</cvrfdoc>
