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

- Update to GCC 13.3 release
- Update to gcc-13 branch head, b7a2697733d19a093cbdd0e200, git8761
- Removed gcc13-pr111731.patch now included upstream

- Add gcc13-amdgcn-remove-fiji.patch removing Fiji support from
  the GCN offload compiler as that is requiring Code Object version 3
  which is no longer supported by llvm18.

- Add gcc13-pr101523.patch to avoid combine spending too much
  compile-time and memory doing nothing on s390x.  [boo#1188441]

- Make requirement to lld version specific to avoid requiring the
  meta-package.

- Add gcc13-pr111731.patch to fix unwinding for JIT code.
  [bsc#1221239]

- Revert libgccjit dependency change.  [boo#1220724]

- Fix libgccjit-devel dependency, a newer shared library is OK.
- Fix libgccjit dependency, the corresponding compiler isn't required.

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

- Add gcc13-sanitizer-remove-crypt-interception.patch to remove
  crypt and crypt_r interceptors.  The crypt API change in SLE15 SP3
  breaks them.  [bsc#1219520]

- Update to gcc-13 branch head, 67ac78caf31f7cb3202177e642, git8285
- Add gcc13-pr88345-min-func-alignment.diff to add support for
  - fmin-function-alignment.  [bsc#1214934]

- Use %{_target_cpu} to determine host and build.

- Update to gcc-13 branch head, fc7d87e0ffadca49bec29b2107, git8250
  * Includes fix for building TVM.  [boo#1218492]

- Add cross-X-newlib-devel requires to newlib cross compilers.
  [boo#1219031]

- Package m2rte.so plugin in the gcc13-m2 sub-package rather than
  in gcc13-devel.  [boo#1210959]
- Require libstdc++6-devel-gcc13 from gcc13-m2 as m2 programs
  are linked against libstdc++6.

- Update to gcc-13 branch head, 36ddb5230f56a30317630a928, git8205

- Update to gcc-13 branch head, 741743c028dc00f27b9c8b1d5, git8109
  * Includes fix for building mariadb on i686.  [bsc#1217667]
  * Remove pr111411.patch contained in the update.

- Avoid update-alternatives dependency for accelerator crosses.
- Package tool links to llvm in cross-amdgcn-gcc13 rather than in
  cross-amdgcn-newlib13-devel since that also has the dependence.
- Depend on llvmVER instead of llvm with VER equal to
  %product_libs_llvm_ver where available and adjust tool discovery
  accordingly.  This should also properly trigger re-builds when
  the patchlevel version of llvmVER changes, possibly changing
  the binary names we link to.  [bsc#1217450]

Package regionServiceClientConfigGCE was updated:

- Update to version 4.1.0  + Replace 162.222.182.90 and 35.187.193.56 (length 4096):
    rgnsrv-gce-asia-northeast1 -&amp;gt; 162.222.182.90 expires in 9 years
    rgnsrv-gce-us-central1 -&amp;gt; 35.187.193.56 expires in 10 years

Package libfastjson was updated:

- fix CVE-2020-12762 integer overflow and out-of-bounds write via a  large JSON file (bsc#1171479)
  add 0001-Fix-CVE-2020-12762.patch

Package _product:SLES-release was updated:

Package python-pyOpenSSL was updated:

- Add CVE-2018-1000807-8_use_after_free_X509.patch to fix  CVE-2018-1000807 (bsc#1111635) and CVE-2018-1000808 (bsc#1111634)
    fix a memory leak and a potential UAF and also #722 (#723)
    sanity check
    bump cryptography minimum version, add changelog
- Add skip_user_after_free_tests.patch to pass the test suite.
- bsc#1021578 add move_cryptography_backend_import.patch to avoid bad
  interaction with python-cryptography package.

Package google-guest-agent was updated:

- Update to version 20240314.00 (bsc#1221900, bsc#1221901)  * 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)
- Refresh patches for new version
  * dont_overwrite_ifcfg.patch

- No need for double %setup.

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

Package kernel-default was updated:

- ACPI: video: check for error while searching for backlight  device parent (bsc#1224686 CVE-2023-52693).
- commit aafdad5

- ACPI: LPIT: Avoid u32 multiplication overflow (bsc#1224627
  CVE-2023-52683).
- commit 57dc5ae

- x86/kprobes: Fix optprobe optimization check with CONFIG_RETHUNK (git-fixes).
- commit 90918cd

- netfilter: nft_set: preserve kabi (bsc#1215420 CVE-2023-4244).
- commit 4994a14

- netfilter: take a reference when looking up nft_sets
  (bsc#1215420 CVE-2023-4244).
- commit 3f2e165

- netfilter: Implement reference counting for nft_sets
  (bsc#1215420 CVE-2023-4244).
- commit b5c850d

- Fix the warning:
  * return makes pointer from integer without a cast [enabled by default] in ../drivers/infiniband/hw/mlx5/srq.c in mlx5_ib_create_srq
  ../drivers/infiniband/hw/mlx5/srq.c: In function 'mlx5_ib_create_srq':
  ../drivers/infiniband/hw/mlx5/srq.c:259:3: warning: return makes pointer from integer without a cast [enabled by default]
- commit d292fa8

- x86/kprobes: Fix kprobes instruction boudary check with CONFIG_RETHUNK (git-fixes).
- commit 29d18ef

- fbdev: savage: Handle err return when savagefb_check_var failed (bsc#1227435 CVE-2024-39475)
- commit 3cf493f

- kgdb: Move the extern declaration kgdb_has_hit_break() to generic  kgdb.h (git-fixes).
- commit 4c96601

- kgdb: Add kgdb_has_hit_break function (git-fixes).
- commit 096e8f7

- x86/ioremap: Fix page aligned size calculation in __ioremap_caller() (git-fixes).
- commit 51d4d78

- blacklist.conf: Blacklist unapplicable commit
- commit 8985317

- x86/numa: Use cpumask_available instead of hardcoded NULL check (git-fixes).
- commit 53fc2d1

- x86/msr: Fix wr/rdmsr_safe_regs_on_cpu() prototypes (git-fixes).
- commit 4cbd29b

- x86/fpu: Return proper error codes from user access functions (git-fixes).
- commit 16cc345

- x86/cpu: Fix AMD erratum #1485 on Zen4-based CPUs (git-fixes).
- commit 530272a

- blacklist.conf: We don't support clang so black list related commit
- commit 0b88169

- x86/boot/e820: Fix typo in e820.c comment (git-fixes).
- commit 3e224a7

- x86/apic: Fix kernel panic when booting with intremap=off and x2apic_phys (git-fixes).
- commit f7c83aa

- x86: __memcpy_flushcache: fix wrong alignment if size &amp;gt; 2^32 (git-fixes).
- commit fe70714

- PM: hibernate: x86: Use crc32 instead of md5 for hibernation e820  integrity check (git-fixes).
- commit 63895f5

- can: pch_can: pch_can_rx_normal: fix use after free (bsc#1225431
  CVE-2021-47520).
- commit 0efd10b

- wifi: nl80211: don't free NULL coalescing rule (bsc#1225835 CVE-2024-36941).
- commit 6927c00

- powerpc/rtas: Prevent Spectre v1 gadget construction in
  sys_rtas() (bsc#1227487).
- commit 564651d

- SUNRPC: Fix loop termination condition in
  gss_free_in_token_pages() (git-fixes).
- sunrpc: fix NFSACL RPC retry on soft mount (git-fixes).
- SUNRPC: Fix gss_free_in_token_pages() (git-fixes).
- nfs: Handle error of rpc_proc_register() in nfs_net_init()
  (git-fixes).
- commit 823e515

- btrfs: do not BUG_ON in link_to_fixup_dir (bsc#1222005
  CVE-2021-47145).
- commit fb0f08c

- soc: fsl: qbman: Use raw spinlock for cgr_lock (bsc#1224683
  CVE-2024-35819).
- commit 4f6a315

- soc: fsl: qbman: Add CGR update function (bsc#1224683
  CVE-2024-35819).
- commit 3b2ce3f

- soc: fsl: qbman: Add helper for sanity checking cgr ops
  (bsc#1224683 CVE-2024-35819).
- commit b33b9fc

- soc: fsl: qbman: Always disable interrupts when taking cgr_lock
  (bsc#1224683 CVE-2024-35819).
- commit 99e6ba5

- drm/amdgpu/debugfs: fix error code when smc register accessors are NULL (git-fixes).
- commit a2420fb

- blacklist.conf: Add c7fcb99877f9 sched/rt: Fix sysctl_sched_rr_timeslice intial value
- commit 71427f6

- blacklist.conf: Add a57415f5d1e4 sched/deadline: Fix sched_dl_global_validate()
- commit b39262b

- sched/deadline: Fix BUG_ON condition for deboosted tasks
  (bsc#1227407).
- commit 58fafac

- dyndbg: fix old BUG_ON in &amp;gt;control parser (bsc#1224647
  CVE-2024-35947).
- commit 52ffbf7

- net: tulip: de4x5: fix the problem that the array 'lp-&amp;gt;phy'
  may be  out of bound (bsc#1225505 CVE-2021-47547).
- commit 605a3ba

- drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL (CVE-2023-52817 bsc#1225569).
- commit d2e5a64

- blacklist.conf: cd90511557fd drm/amdgpu/vkms: fix a possible null pointer dereference
- commit d0def0c

- blacklist.conf: 80285ae1ec87 drm/amdgpu: Fix potential null pointer derefernce
- commit 95c5571

- blacklist.conf: 406e8845356d drm/amd: check num of link levels when update pcie param
- commit f93c72c

- drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga (CVE-2023-52819 bsc#1225532).
- commit d196cd8

- drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7 (CVE-2023-52818 bsc#1225530).
- commit d67dcd9

- blacklist.conf: 282c1d793076 drm/amdkfd: Fix shift out-of-bounds issue
- commit cc813e8

- drm/amd/display: Avoid NULL dereference of timing generator (CVE-2023-52753 bsc#1225478).
- commit f316fd9

- blacklist.conf: 31729e8c21ec drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11
- commit 785f136

- blacklist.conf: add 2a19b28f7929866e1cec92a3619f4de9f2d20005.
- commit a4c7fa2

- drm/arm/malidp: fix a possible null pointer dereference (CVE-2024-36014 bsc#1225593).
- commit 3f35223

- llc: make llc_ui_sendmsg() more robust against bonding changes
  (CVE-2024-26636 bsc#1221659).
- commit 727fec1

- llc: Drop support for ETH_P_TR_802_2 (CVE-2024-26635
  bsc#1221656).
- commit 4792924

- wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()
  (bsc#1224622 CVE-2024-35828).
- commit 9f39e76

- nfc: nci: assert requested protocol is valid (bsc#1220833, CVE-2023-52507).
- commit 78bd01e

- md: fix resync softlockup when bitmap size is less than array
  size (CVE-2024-38598, bsc#1226757).
- commit e578184

- dm snapshot: fix lockup in dm_exception_table_exit (bsc#1224743,
  CVE-2024-35805).
- dm: call the resume method on internal suspend (bsc#1223188,
  CVE-2024-26880).
- dm rq: don't queue request to blk-mq during DM suspend
  (bsc#1225357, CVE-2021-47498).
- bcache: avoid oversized read request in cache missing code path
  (bsc#1224965, CVE-2021-47275).
- bcache: remove bcache device self-defined readahead
  (bsc#1224965, CVE-2021-47275).
- commit 0df91b9

- net/mlx5e: nullify cq-&amp;gt;dbg pointer in mlx5_debug_cq_remove() (bsc#1225229 CVE-2021-47438)
- commit dd90392

- net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path (bsc#1225229 CVE-2021-47438)
- commit eebb92a

- usb-storage: alauda: Check whether the media is initialized
  (CVE-2024-38619 bsc#1226861).
- commit 8f69e1a

- iavf: free q_vectors before queues in iavf_disable_vf
  (CVE-2021-47201 bsc#1222792).
- commit 5fa75c2

- blacklist.conf: 9cb46b31f3d0 drm/xe/xe_migrate: Cast to output precision before multiplying operands
- commit 6d5246f

- ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()
  (CVE-2024-26641 bsc#1221654).
- commit 785d6bf

- hsr: Fix uninit-value access in hsr_get_node() (bsc#1223021
  CVE-2024-26863).
- net: hsr: fix placement of logical operator in a multi-line
  statement (bsc#1223021).
- hsr: Fix uninit-value access in hsr_get_node() (bsc#1223021
  CVE-2024-26863).
- net: hsr: fix placement of logical operator in a multi-line
  statement (bsc#1223021).
- commit bea7af4

- ip6_tunnel: fix NEXTHDR_FRAGMENT handling in
  ip6_tnl_parse_tlv_enc_lim() (CVE-2024-26633 bsc#1221647).
- commit 6bed746

- blacklist.conf: ecedd99a9369 drm/amd/display: Skip on writeback when it's not applicable
- commit 7f9ee16

- net: sock: preserve kabi for sock (bsc#1221010 CVE-2021-47103).
- commit 00f2734

- inet: fully convert sk-&amp;gt;sk_rx_dst to RCU rules (bsc#1221010
  CVE-2021-47103).
- commit 955aaf2

- Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout
  (bsc#1224177 CVE-2024-27399).
- commit f1f5272

- ACPI: processor_idle: Fix memory leak in
  acpi_processor_power_exit() (bsc#1223043 CVE-2024-26894).
- commit 69014d4

- scsi: bnx2fc: Remove spin_lock_bh while releasing resources
  after upload (bsc#1224767 CVE-2024-36919).
- scsi: lpfc: Move NPIV's transport unregistration to after
  resource clean up (bsc#1225898 CVE-2024-36592).
- scsi: bnx2fc: Remove spin_lock_bh while releasing resources
  after upload (bsc#1224767 CVE-2024-36919).
- scsi: lpfc: Move NPIV's transport unregistration to after
  resource clean up (bsc#1225898 CVE-2024-36592).
- commit 011e140

- selinux: fix double free of cond_list on error paths
  (bsc#1226699 CVE-2022-48740).
- commit c27761a

- fs/9p: fix uninitialized values during inode evict (bsc#1225815
  CVE-2024-36923).
- commit fccda1c

- btrfs: fix crash on racing fsync and size-extending write into
  prealloc (bsc#1227101 CVE-2024-37354).
- btrfs: add helper to truncate inode items when logging inode
  (bsc#1227101 CVE-2024-37354).
- btrfs: don't set the full sync flag when truncation does not
  touch extents (bsc#1227101 CVE-2024-37354).
- btrfs: fix misleading and incomplete comment of btrfs_truncate()
  (bsc#1227101 CVE-2024-37354).
- btrfs: make btrfs_truncate_inode_items take btrfs_inode
  (bsc#1227101 CVE-2024-37354).
- commit 25e24a4

- blacklist.conf: kABI
- commit 2c68edf

- usb: typec: tcpm: Skip hard reset when in error recovery
  (git-fixes).
- commit 74f41bf

- blacklist.conf: false positive
- commit b55e7fd

- bpf, scripts: Correct GPL license name (git-fixes).
- commit d41908e

- Update
  patches.suse/0006-dm-btree-remove-fix-use-after-free-in-rebalance_chil.patch
  (git-fixes CVE-2021-47600 bsc#1226575).
- Update
  patches.suse/PCI-pciehp-Fix-infinite-loop-in-IRQ-handler-upon-pow.patch
  (git-fixes CVE-2021-47617 bsc#1226614).
- Update
  patches.suse/USB-core-Fix-hang-in-usb_kill_urb-by-adding-memory-b.patch
  (git-fixes CVE-2022-48760 bsc#1226712).
- Update
  patches.suse/audit-improve-robustness-of-the-audit-queue-handling.patch
  (bsc#1204514 CVE-2021-47603 bsc#1226577).
- Update
  patches.suse/drm-vmwgfx-Fix-stale-file-descriptors-on-failed-user.patch
  (CVE-2022-22942 bsc#1195065 CVE-2022-48771 bsc#1226732).
- Update patches.suse/igbvf-fix-double-free-in-igbvf_probe.patch
  (git-fixes CVE-2021-47589 bsc#1226557).
- Update
  patches.suse/isdn-cpai-check-ctr-cnr-to-avoid-array-index-out-of-bound.patch
  (bsc#1191958 CVE-2021-43389 CVE-2021-4439 bsc#1226670).
- Update
  patches.suse/net-ieee802154-ca8210-Stop-leaking-skb-s.patch
  (git-fixes CVE-2022-48722 bsc#1226619).
- Update
  patches.suse/netfilter-complete-validation-of-user-input.patch
  (git-fixes CVE-2024-35896 bsc#1224662 CVE-2024-35962
  bsc#1224583).
- Update patches.suse/phylib-fix-potential-use-after-free.patch
  (bsc#1119113 FATE#326472 CVE-2022-48754 bsc#1226692).
- Update
  patches.suse/ring-buffer-Fix-a-race-between-readers-and-resize-checks.patch
  (bsc#1222893 CVE-2024-38601 bsc#1226876).
- Update
  patches.suse/scsi-bnx2fc-Flush-destroy_work-queue-before-calling-bnx2fc_interface_put
  (git-fixes CVE-2022-48758 bsc#1226708).
- Update patches.suse/scsi-bnx2fc-Make-bnx2fc_recv_frame-mp-safe
  (git-fixes CVE-2022-48715 bsc#1226621).
- Update
  patches.suse/scsi-libfc-Fix-potential-NULL-pointer-dereference-in-fc_lport_ptp_setup.patch
  (git-fixes CVE-2023-52809 bsc#1225556).
- Update
  patches.suse/scsi-qla2xxx-Fix-off-by-one-in-qla_edif_app_getstats.patch
  (git-fixes CVE-2024-36025 bsc#1225704).
- Update
  patches.suse/scsi-scsi_debug-Sanity-check-block-descriptor-length-in-resp_mode_select
  (git-fixes CVE-2021-47576 bsc#1226537).
- Update
  patches.suse/scsi-target-core-Add-TMF-to-tmr_list-handling.patch
  (bsc#1223018 CVE-26845 CVE-2024-26845).
- Update
  patches.suse/tipc-improve-size-validations-for-received-domain-re.patch
  (bsc#1195254 CVE-2022-0435 CVE-2022-48711 bsc#1226672).
- commit c2edf0b

- tcp: do not accept ACK of bytes we never sent (CVE-2023-52881
  bsc#1225611).
- commit d93d95b

- usb: port: Don't try to peer unused USB ports based on location
  (git-fixes).
- commit c96b5c5

- blacklist.conf: logging only
- commit b17cfa5

- x86/tsc: Trust initial offset in architectural TSC-adjust MSRs
  (bsc#1222015 bsc#1226962).
- commit c9f769c

- iommu/vt-d: Allocate local memory for page request queue
  (git-fixes).
- commit 541ce64

- iommu/amd: Fix sysfs leak in iommu init (git-fixes).
- commit cdae1dd

- KVM: x86: Handle SRCU initialization failure during page track
  init (CVE-2021-47407, bsc#1225306).
- commit 61b3e37

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

- net/9p: fix uninit-value in p9_client_rpc() (CVE-2024-39301 bsc#1226994).
- commit 1a033be

- media: lgdt3306a: Add a check against null-pointer-def
  (CVE-2022-48772 bsc#1226976).
- commit 79e986b

- fpga: manager: add owner module and take its refcount
  (CVE-2024-37021 bsc#1226950).
- commit 580ed12

- fpga: region: add owner module and take its refcount
  (CVE-2024-35247 bsc#1226948).
- commit 75fbd8f

- fpga: bridge: add owner module and take its refcount
  (CVE-2024-36479 bsc#1226949).
- commit 410068f

- enic: Validate length of nl attributes in enic_set_vf_port
  (CVE-2024-38659 bsc#1226883).
- net: fec: remove .ndo_poll_controller to avoid deadlocks
  (CVE-2024-38553 bsc#1226744).
- net/mlx5e: Fix netif state handling (CVE-2024-38608
  bsc#1226746).
- eth: sungem: remove .ndo_poll_controller to avoid deadlocks
  (CVE-2024-38597 bsc#1226749).
- net: amd-xgbe: Fix skb data length underflow (CVE-2022-48743
  bsc#1226705).
- net: systemport: Add global locking for descriptor lifecycle
  (CVE-2021-47587 bsc#1226567).
- commit 6fa5a1e

- usb: xhci-plat: fix crash when suspend if remote wake enable
  (CVE-2022-48761 bsc#1226701).
- commit 6918857

- virtio-blk: fix implicit overflow on virtio_max_dma_size
  (bsc#1225573 CVE-2023-52762).
- commit 630807b

- btrfs: fix use-after-free after failure to create a snapshot
  (bsc#1226718 CVE-2022-48733).
- commit bc8f6e2

- vfio/platform: Create persistent IRQ handlers (bsc#1222809
  CVE-2024-26813).
- commit a912042

- Update to fix a compiling error,
  patches.suse/raid1-fix-use-after-free-for-original-bio-in-raid1_-fcf3.patch.
- commit 4738bf0

- s390/ap: Fix crash in AP internal function modify_bitmap()
  (CVE-2024-38661 bsc#1226996 git-fixes).
- commit 642fe77

- block: fix overflow in blk_ioctl_discard() (bsc#1225770
  CVE-2024-36917).
- commit fb1867c

- epoll: be better about file lifetimes (bsc#1226610
  CVE-2024-38580).
- commit da86de7

- KVM: allow KVM_BUG/KVM_BUG_ON to handle 64-bit cond (git-fixes).
- commit 63ce06d

- drm/nouveau: fix off by one in BIOS boundary checking (bsc#1226716 CVE-2022-48732)
- commit bed5212

- Update references tag
  patches.suse/Bluetooth-Disconnect-if-E0-is-used-for-Level-4.patch
  (bsc#1171988 CVE-2020-10135 bsc#1218148 CVE-2023-24023).
- commit b41c397

- mm: Avoid overflows in dirty throttling logic (bsc#1222364
  CVE-2024-26720).
- commit 6f98632

- media: stk1160: fix bounds checking in stk1160_copy_video()
  (CVE-2024-38621 bsc#1226895).
- commit 617f122

- dma-buf/sw-sync: don't enable IRQ from sync_print_obj()
  (CVE-2024-38780 bsc#1226886).
- commit 0a1e3b6

- nvmet: fix ns enable/disable possible hang (git-fixes).
- commit 128ca3f

- ecryptfs: Fix buffer size for tag 66 packet  (bsc#1226634, CVE-2024-38578).
- commit 41891c0

- stm class: Fix a double free in stm_register_device()
  (CVE-2024-38627 bsc#1226857).
- commit b4ea481

- blacklist.conf: kABI
- commit 516146e

- crypto: bcm - Fix pointer arithmetic (bsc#1226637
  CVE-2024-38579).
- commit be1545d

- drm/amd/display: Fix potential index out of bounds in color (bsc#1226767 CVE-2024-38552)
- commit fdaaa54

- drm/mediatek: Add 0 size check to mtk_drm_gem_obj (bsc#1226735 CVE-2024-38549)
- commit b67d29d

- drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable (bsc#1226698 CVE-2022-48756)
- commit bd95a05

- net: usb: rtl8150 fix unintiatilzed variables in
  rtl8150_get_link_ksettings (git-fixes).
- commit 996e5c4

- RDMA/hns: Fix UAF for cq async event (bsc#1226595 CVE-2024-38545)
- commit 68cd4b9

- RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt (bsc#1226597 CVE-2024-38544)
- commit da8c605

- RDMA/mlx5: Add check for srq max_sge attribute (git-fixes)
- commit 6ee55be

- drm: vc4: Fix possible null pointer dereference (CVE-2024-38546
  bsc#1226593).
- commit f5c6e94

- wifi: carl9170: add a proper sanity check for endpoints
  (CVE-2024-38567 bsc#1226769).
- rpmsg: char: Fix race between the release of rpmsg_ctrldev
  and cdev (CVE-2022-48759 bsc#1226711).
- commit 1d933f6

- wifi: ar5523: enable proper endpoint verification
  (CVE-2024-38565 bsc#1226747).
- commit 7f113b6

- mac80211: track only QoS data frames for admission control
  (CVE-2021-47602 bsc#1226554).
- commit 6d84852

- ALSA: timer: Set lower bound of start tick time (CVE-2024-38618
  bsc#1226754).
- commit ea3c02c

- blacklist.conf: Add 7af443ee16976 sched/core: Require cpu_active() in select_task_rq(), for user tasks
- commit 35a10db

- bsc#1225894: Fix build warning
  Fix the following build warning.
  * unused-variable (i) in ../drivers/gpu/drm/amd/amdkfd/kfd_device.c in kgd2kfd_resume
  ../drivers/gpu/drm/amd/amdkfd/kfd_device.c: In function 'kgd2kfd_resume':
  ../drivers/gpu/drm/amd/amdkfd/kfd_device.c:621:11: warning: unused variable 'i' [-Wunused-variable]
- commit e16e5ba

- bsc#1225894: Fix patch references
- commit 7b4670a

- net/mlx5: Properly link new fs rules into the tree (bsc#1224588
  CVE-2024-35960).
- commit 14f14ea

- net/mlx5e: fix a double-free in arfs_create_groups (bsc#1224605
  CVE-2024-35835).
- commit 2cc5781

- firmware: arm_scpi: Fix string overflow in SCPI genpd driver (bsc#1226562 CVE-2021-47609)
- commit 4642449

- Fix compilation
- commit 3f5119e

- net: ena: Fix incorrect descriptor free behavior (bsc#1224677
  CVE-2024-35958).
- commit 8f4768d

- bonding: stop the device in bond_setup_by_slave() (bsc#1224946
  CVE-2023-52784).
- commit da74b6f

- blacklist.conf: bsc#1225555 CVE-2023-52808
  patches code not present
- commit 35c5de8

- blacklist.conf: bsc#1223013 CVVE-2024-26482
  does not apply
- commit c785e5a

- blacklist.conf: bsc#1222879 CVE-2021-47193
  breaks kABI
- commit 5ac2f95

- blacklist.conf: bsc#1225559 CVE-2023-5281
  Does not apply cleanly at all, and addresses
  a corner case that it knows is rare.
- commit 66930cf

- scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
  (bsc#1224651 CVE-2024-35930).
- scsi: target: core: Add TMF to tmr_list handling (bsc#1223018
  CVE-26845).
- scsi: scsi_debug: Fix out-of-bound read in resp_readcap16()
  (bsc#122286 CVE-2021-47191).
- commit 3100b52

- usb: fix various gadget panics on 10gbps cabling (CVE-2021-47267
  bsc#1224993).
- commit 3336e4a

- amd/amdkfd: sync all devices to wait all processes being evicted (bsc#1225872 CVE-2024-36949)
- commit aa91737

- drm/amdkfd: Rework kfd_locked handling (bsc#1225872)
- commit 030a69d

- drm/vmwgfx: Fix invalid reads in fence signaled events (bsc#1225872 CVE-2024-36960)
- commit fe8da4d

- nfsd: optimise recalculate_deny_mode() for a common case
  (bsc#1217912).
- commit 90c611c

- NFSv4: Always clear the pNFS layout when handling ESTALE
  (bsc#1221791).
- NFSv4: nfs_set_open_stateid must not trigger state recovery
  for closed state (bsc#1221791).
- PNFS for stateid errors retry against MDS first (bsc#1221791).
- commit fcd364d

- block: prevent division by zero in blk_rq_stat_sum()
  (bsc#1224661 CVE-2024-35925).
- commit 7fd346a

- ext4: fix corruption during on-line resize (bsc#1224735
  CVE-2024-35807).
- commit 8431549

- fat: fix uninitialized field in nostale filehandles (git-fixes
  CVE-2024-26973 bsc#1223641).
- commit 8b4f3fd

- ext4: avoid online resizing failures due to oversized flex bg
  (bsc#1222080 CVE-2023-52622).
- commit a81bee5

- nfc: fix potential NULL pointer deref in nfc_genl_dump_ses_done
  (CVE-2021-47518 bsc#1225372).
- commit d0fabf7

- net_sched: fix NULL deref in fifo_set_limit()
  (CVE-2021-47418 bsc#1225337).
- commit 54048d4

- net: validate lwtstate-&amp;gt;data before returning from skb_tunnel_info()
  (CVE-2021-47309 bsc#1224967).
- commit 2b76537

- net: fix uninit-value in caif_seqpkt_sendmsg
  (CVE-2021-47297 bsc#1224976).
- commit 39164d4

- net/sched: act_skbmod: Skip non-Ethernet packets
  (CVE-2021-47293 bsc#1224978).
- commit aedefe0

- netrom: Decrease sock refcount when sock timers expire
  (CVE-2021-47294 bsc#1224977).
- commit 44bce11

- ipv6: Fix infinite recursion in fib6_dump_done() (CVE-2024-35886
  bsc#1224670).
- commit 5d20998

- tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
  (CVE-2024-36016 bsc#1225642).
- commit f5c4f31

- net: macb: fix use after free on rmmod (CVE-2021-47372
  bsc#1225184).
- commit 5bb5ee7

- btrfs: use correct compare function of dirty_metadata_bytes (git-fixes)
- commit d51a7ff

- Btrfs: fix memory and mount leak in btrfs_ioctl_rm_dev_v2() (git-fixes)
- commit 4b455f0

- btrfs: fix describe_relocation when printing unknown flags (git-fixes)
- commit a147519

- btrfs: add barriers to btrfs_sync_log before log_commit_wait wakeups (git-fixes)
- commit 0487247

- btrfs: fix crash when trying to resume balance without the resume flag (git-fixes)
- commit f0fa7bc

- Btrfs: clean up resources during umount after trans is aborted (git-fixes)
- commit c78d131

- Btrfs: bail out on error during replay_dir_deletes (git-fixes)
- commit 7a8f6ce

- Btrfs: fix NULL pointer dereference in log_dir_items (git-fixes)
- commit 02cab92

- Btrfs: send, fix issuing write op when processing hole in no data mode (git-fixes)
- Refresh
  patches.suse/btrfs-send-fix-incorrect-file-layout-after-hole-punching-beyond-eof.patch.
- commit f710800

- Btrfs: fix unexpected EEXIST from btrfs_get_extent (git-fixes)
- commit 82c1e6b

- btrfs: tree-check: reduce stack consumption in check_dir_item (git-fixes)
- commit 36aca35

- btrfs: fix false EIO for missing device (git-fixes)
- Refresh
  patches.suse/btrfs-ensure-that-a-dup-or-raid1-block-group-has-exactly-two-stripes.patch
- commit 01544ea

- USB: serial: option: add Quectel EG912Y module support
  (git-fixes).
- commit a8d3e25

- blacklist.conf: pure cleanup
- commit c59c78d

- USB: serial: option: add Quectel RM500Q R13 firmware support
  (git-fixes).
- commit b3dedc2

- USB: serial: option: add Foxconn T99W265 with new baseline
  (git-fixes).
- commit 51f747d

- net: usb: smsc95xx: fix changing LED_SEL bit value updated
  from EEPROM (git-fixes).
- commit d6ed297

- ocfs2: fix sparse warnings (bsc#1219224).
- ocfs2: speed up chain-list searching (bsc#1219224).
- ocfs2: adjust enabling place for la window (bsc#1219224).
- ocfs2: improve write IO performance when fragmentation is high
  (bsc#1219224).
- commit d862a97

- smb: client: fix use-after-free bug in
  cifs_debug_data_proc_show() (bsc#1225487, CVE-2023-52752).
- commit b2bff17

- blkcg: Fix multiple bugs in blkcg_activate_policy()
  (CVE-2021-47379 bsc#1225203).
- blkcg: blkcg_activate_policy() should initialize ancestors first
  (CVE-2021-47379 bsc#1225203).
- commit 5e6941f

- blacklist.conf: bsc#1225047 CVE-2021-47328: breaks kABI
  Also, does not apply.
- commit 55744fb

- blk-cgroup: fix UAF by grabbing blkcg lock before destroying
  blkg pd (CVE-2021-47379 bsc#1225203).
- commit 26f8206

- blacklist.conf: Blacklist 618f003199c61
- commit f552be9

- atl1c: Work around the DMA RX overflow issue (CVE-2023-52834
  bsc#1225599).
- commit c880bf0

- btrfs: lock the inode in shared mode before starting fiemap
  (bsc#1225484 CVE-2023-52737).
- commit e4a79d3

- ext4: correct offset of gdb backup in non meta_bg group to
  update_backups (bsc#1224735 CVE-2024-35807).
- commit 57ba8ce

- raid1: fix use-after-free for original bio in raid1_write_request()
  (bsc#1221097, bsc#1224572, CVE-2024-35979).
- commit daf8372

- fs/9p: only translate RWX permissions for plain 9P2000
  (bsc#1225866 CVE-2024-36964).
- commit 7cf061b

- media: imon: fix access to invalid resource for the second
  interface (CVE-2023-52754 bsc#1225490).
- commit 0f818a4

- firewire: ohci: mask bus reset interrupts between ISR and
  bottom half (CVE-2024-36950 bsc#1225895).
- commit 342de59

- pinctrl: core: delete incorrect free in pinctrl_enable()
  (CVE-2024-36940 bsc#1225840).
- commit 6103cd4

- staging: rtl8192e: Fix use after free in
  _rtl92e_pci_disconnect() (CVE-2021-47571 bsc#1225518).
- commit 9243acc

- media: gspca: cpia1: shift-out-of-bounds in set_flicker
  (CVE-2023-52764 bsc#1225571).
- wifi: mac80211: don't return unset power in
  ieee80211_get_tx_power() (CVE-2023-52832 bsc#1225577).
- commit 74cf739

- Bluetooth: qca: add missing firmware sanity checks
  (CVE-2024-36880 bsc#1225722).
- commit 1f313de

- drm/msm: Fix null pointer dereference on pointer edp (bsc#1225261 CVE-2021-47445)
- commit 7365fdb

- rpm/kernel-obs-build.spec.in: Add iso9660 (bsc#1226212)
  Some builds don't just create an iso9660 image, but also mount it during
  build.
- commit aaee141

- llc: verify mac len before reading mac header
  (CVE-2023-52843 bsc#1224951).
- commit 048fdd1

- drm/sched: Avoid data corruptions (bsc#1225140 CVE-2021-47354)
- commit 735d57e

- nfc: llcp: fix nfc_llcp_setsockopt() unsafe copies
  (CVE-2024-36915 bsc#1225758).
- commit d2aa3fc

- rpm/kernel-obs-build.spec.in: Add networking modules for docker
  (bsc#1226211)
  docker needs more networking modules, even legacy iptable_nat and _filter.
- commit 415e132

- Bluetooth: Add more enc key size check (bsc#1218148
  CVE-2023-24023).
- commit 8b7d4c7

- rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation
  (CVE-2024-36017 bsc#1225681).
- commit eee2828

- netfilter: complete validation of user input
  (git-fixes CVE-2024-35896 bsc#1224662).
- commit bd2bc6c

- tcp: fix page frag corruption on page fault
  (CVE-2021-47544 bsc#1225463).
- commit 0c69f93

- netfilter: validate user input for expected length
  (CVE-2024-35896 bsc#1224662).
- commit d09d89a

- Bluetooth: Normalize HCI_OP_READ_ENC_KEY_SIZE cmdcmplt
  (bsc#1218148 CVE-2023-24023).
- commit be61b35

- arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
  (git-fixes).
- commit a33c0aa

- fbmon: prevent division by zero in fb_videomode_from_videomode() (bsc#1224660 CVE-2024-35922)
- commit 9990cdc

- bna: ensure the copied buf is NUL terminated (CVE-2024-36934
  bsc#1225760).
- commit 5e5c793

- tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
  (CVE-2023-52845 bsc#1225585).
- commit 28beea5

- blacklist.conf: Add 1971d13ffa84a &amp;quot;af_unix: Suppress false-positive lockdep splat for spin_lock() in __unix_gc().&amp;quot;
- commit 9ab8e4f

- HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent
  lock-up (bsc#1224552 CVE-2024-35997).
- commit 31522d3

- wifi: nl80211: reject iftype change with mesh ID change
  (CVE-2024-27410 bsc#1224432).
- commit 18882c6

- fix compat handling of FICLONERANGE, FIDEDUPERANGE and
  FS_IOC_FIEMAP (bsc#1225848).
- blacklist.conf:
- fs: make fiemap work from compat_ioctl (bsc#1225848).
- commit e6c580c

- perf/core: Bail out early if the request AUX area is out of
  bound (bsc#1225602 CVE-2023-52835).
- commit 0b197bf

- powerpc/imc-pmu: Add a null pointer check in
  update_events_in_group() (bsc#1224504 CVE-2023-52675).
- commit 5ed0541

- blacklist.conf: CVE-2024-35956 bsc#1224674: not applicable bsc#1225945
  Quoting bsc#1225945#c11:
  &amp;quot;So the upstream 6.5 kernel commit (1b53e51a4a8f (&amp;quot;btrfs: don't commit
  transaction for every subvol create&amp;quot;)
  ) was never backported to SLE, so that fix eb96e221937a (&amp;quot;btrfs: fix
  unwritten extent buffer after snapshotting a new subvolume&amp;quot;) was never
  backported.&amp;quot;
- commit 13b6119

- usb: gadget: f_fs: Fix race between aio_cancel() and AIO
  request complete (CVE-2024-36894 bsc#1225749).
- commit 66229f2

- proc/vmcore: fix clearing user buffer by properly using
  clear_user() (CVE-2021-47566 bsc#1225514).
- commit 4f35255

- usb: dwc2: fix possible NULL pointer dereference caused by
  driver concurrency (CVE-2023-52855 bsc#1225583).
- commit 304ea43

- Refresh patches.kabi/net-preserve-kabi-for-sk_buff.patch.
- commit fa7929b

- net: preserve kabi for sk_buff (CVE-2024-26921 bsc#1223138).
- commit 726f363

- inet: inet_defrag: prevent sk release while still in use
  (CVE-2024-26921 bsc#1223138).
- commit 7846939

- xhci: Fix commad ring abort, write all 64 bits to CRCR register
  (CVE-2021-47434 bsc#1225232).
- commit d92fac3

- xhci: Fix command ring pointer corruption while aborting a
  command (CVE-2021-47434 bsc#1225232).
- blacklist.conf: taken so that the correct fix applies
- commit ea90837

- xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING
  (bsc#1224575 CVE-2024-35976).
- commit 641c7c4

- usb: fix various gadgets null ptr deref on 10gbps cabling
  (CVE-2021-47270 bsc#1224997).
- commit 00c58e2

- usb: udc: remove warning when queue disabled ep (CVE-2024-35822
  bsc#1224739).
- commit dcaf30a

- blacklist.conf: add cleanup fix that breaks kABI
- commit cae1961

- bpf, skmsg: Fix NULL pointer dereference in
  sk_psock_skb_ingress_enqueue (bsc#1225761 CVE-2024-36938).
- commit 24fab08

- drm/client: Fully protect modes with dev-&amp;gt;mode_config.mutex (CVE-2024-35950 bsc#1224703).
- commit f0cb811

- smb: client: fix potential deadlock when releasing mids
  (bsc#1225548, CVE-2023-52757).
- commit 00dc86e

- smb: client: fix potential UAF in is_valid_oplock_break()
  (bsc#1224763, CVE-2024-35863).
- commit be79366

- smb: client: fix potential UAF in cifs_stats_proc_write()
  (bsc#1224678, CVE-2024-35868).
- commit 7c5946d

- smb: client: fix potential UAF in cifs_stats_proc_show()
  (bsc#1224664, CVE-2024-35867).
- commit adb391f

- smb: client: fix potential UAF in cifs_debug_files_proc_show()
  (bsc#1223532, CVE-2024-26928).
- commit 92bb153

- smb: client: fix UAF in smb2_reconnect_server() (bsc#1224672,
  CVE-2024-35870).
- commit 4eabe16

- smb: client: fix potential UAF in smb2_is_valid_lease_break()
  (bsc#1224765, CVE-2024-35864).
- commit 688ad5f

- smb: client: fix potential UAF in smb2_is_network_name_deleted()
  (bsc#1224764, CVE-2024-35862).
- commit 6bbd54b

- smb3: fix lock ordering potential deadlock in
  cifs_sync_mid_result (bsc#1224549, CVE-2024-35998).
- commit fbe7cb6

- smb: client: fix potential UAF in smb2_is_valid_oplock_break()
  (bsc#1224668, CVE-2024-35865).
- commit 77a46ab

- nvme-tcp: fix UAF when detecting digest errors (CVE-2022-48686 bsc#1223948).
  Update blacklist.conf: remove entry
- commit f159215

- nvme-loop: fix memory leak in nvme_loop_create_ctrl() (CVE-2021-47074 bsc#1220854).
  Update blacklist.conf: remove entry
- commit 5f6a5df

- nvme-rdma: destroy cm id before destroy qp to avoid use after
  free (CVE-2021-47378 bsc#1225201).
- commit 599a36a

- nvmet: fix a use-after-free (CVE-2022-48697 bsc#1223922).
  Update blacklist.conf: drop entry from it
- commit 5e496a4

- nvme-fc: do not wait in vain when unloading module
  (CVE-2024-26846 bsc#1223023).
- commit 365a6dd

- blacklist.conf: add d380ce70058a4ccddc3e5f5c2063165dc07672c6
  netrom: Fix data-races around sysctl_net_busy_read
  (CVE-2024-27419 bsc#1224759)
- commit 9b21914

- net/tls: Fix flipped sign in tls_err_abort() calls
  (CVE-2021-47496 bsc#1225354)
- commit af28ae7

- Update
  patches.suse/0004-dm-fix-mempool-NULL-pointer-race-when-completing-IO.patch
  (git-fixes bsc#1225247 CVE-2021-47435).
- Update
  patches.suse/0022-dm-btree-remove-assign-new_root-only-when-removal-su.patch
  (git fixes bsc#1225155 CVE-2021-47343).
- Update
  patches.suse/0066-virtio-blk-Fix-memory-leak-among-suspend-resume-procedure.patch
  (git-fixes bsc#1225054 CVE-2021-47319).
- Update
  patches.suse/HID-betop-fix-slab-out-of-bounds-Write-in-betop_prob.patch
  (git-fixes bsc#1207186 bsc#1225303 CVE-2021-47404).
- Update
  patches.suse/IB-hfi1-Fix-leak-of-rcvhdrtail_dummy_kvaddr.patch
  (git-fixes bsc#1225438 CVE-2021-47523).
- Update
  patches.suse/IB-mlx5-Fix-initializing-CQ-fragments-buffer.patch
  (git-fixes bsc#1224954 CVE-2021-47261).
- Update
  patches.suse/IB-qib-Protect-from-buffer-overflow-in-struct-qib_us.patch
  (git-fixes bsc#1224904 CVE-2021-47485).
- Update
  patches.suse/RDMA-cma-Ensure-rdma_addr_cancel-happens-before-issu.patch
  (git-fixes bsc#1225318 CVE-2021-47391).
- Update
  patches.suse/RDMA-cma-Fix-rdma_resolve_route-memory-leak.patch
  (git-fixes bsc#1225157 CVE-2021-47345).
- Update
  patches.suse/SUNRPC-Fix-RPC-client-cleaned-up-the-freed-pipefs-de.patch
  (git-fixes bsc#1225008 CVE-2023-52803).
- Update
  patches.suse/blktrace-Fix-uaf-in-blk_trace-access-after-removing-.patch
  (bsc#1191452 bsc#1225193 CVE-2021-47375).
- Update patches.suse/can-peak_pci-peak_pci_remove-fix-UAF.patch
  (git-fixes bsc#1225256 CVE-2021-47456).
- Update
  patches.suse/cifs-Fix-use-after-free-in-rdata-read_into_pages-.patch
  (bsc#1190317 bsc#1225479 CVE-2023-52741).
- Update
  patches.suse/cifs-prevent-NULL-deref-in-cifs_compose_mount_options-.patch
  (bsc#1185902 bsc#1224961 CVE-2021-47307).
- Update
  patches.suse/dma-buf-sync_file-Don-t-leak-fences-on-merge-failure.patch
  (git-fixes bsc#1224968 CVE-2021-47305).
- Update
  patches.suse/drm-Fix-use-after-free-read-in-drm_getunique.patch
  (git-fixes bsc#1224982 CVE-2021-47280).
- Update
  patches.suse/ftrace-Do-not-blindly-read-the-ip-address-in-ftrace_bug.patch
  (git-fixes bsc#1224966 CVE-2021-47276).
- Update patches.suse/gfs2-ignore-negated-quota-changes.patch
  (git-fixes bsc#1225560 CVE-2023-52759).
- Update
  patches.suse/i40e-Fix-freeing-of-uninitialized-misc-IRQ-vector.patch
  (bsc#1101816 FATE#325147 FATE#325149 bsc#1225367
  CVE-2021-47424).
- Update
  patches.suse/igb-Fix-use-after-free-error-during-reset.patch
  (git-fixes bsc#1224916 CVE-2021-47301).
- Update
  patches.suse/igc-Fix-use-after-free-error-during-reset.patch
  (git-fixes bsc#1224917 CVE-2021-47302).
- Update
  patches.suse/ipv4-ipv6-Fix-handling-of-transhdrlen-in-__ip-6-_app.patch
  (git-fixes bsc#1220928 CVE-2023-52527).
- Update
  patches.suse/isdn-mISDN-netjet-Fix-crash-in-nj_probe.patch
  (git-fixes bsc#1224987 CVE-2021-47284).
- Update
  patches.suse/isofs-Fix-out-of-bound-access-for-corrupted-isofs-im.patch
  (bsc#1194591 bsc#1225198 CVE-2021-47478).
- Update
  patches.suse/kprobes-Fix-possible-use-after-free-issue-on-kprobe-registration.patch
  (git-fixes bsc#1224676 CVE-2024-35955).
- Update
  patches.suse/l2tp-pass-correct-message-length-to-ip6_append_data.patch
  (git-fixes bsc#1222667 CVE-2024-26752).
- Update
  patches.suse/mISDN-fix-possible-use-after-free-in-HFC_cleanup.patch
  (git-fixes bsc#1225143 CVE-2021-47356).
- Update
  patches.suse/media-zr364xx-fix-memory-leak-in-zr364xx_start_readp.patch
  (git-fixes bsc#1224922 CVE-2021-47344).
- Update
  patches.suse/net-USB-Fix-wrong-direction-WARNING-in-plusb.c.patch
  (git-fixes bsc#1225482 CVE-2023-52742).
- Update
  patches.suse/net-hns3-do-not-allow-call-hns3_nic_net_open-repeate.patch
  (git-fixes bsc#1225329 CVE-2021-47400).
- Update
  patches.suse/net-mdiobus-Fix-memory-leak-in-__mdiobus_register.patch
  (git-fixes bsc#1225189 CVE-2021-47472).
- Update
  patches.suse/net-mlx4_en-Fix-an-use-after-free-bug-in-mlx4_en_try.patch
  (git-fixes bsc#1225453 CVE-2021-47541).
- Update
  patches.suse/net-nfc-rawsock.c-fix-a-permission-check-bug.patch
  (git-fixes bsc#1224981 CVE-2021-47285).
- Update patches.suse/net-qcom-emac-fix-UAF-in-emac_remove.patch
  (git-fixes bsc#1225010 CVE-2021-47311).
- Update patches.suse/net-ti-fix-UAF-in-tlan_remove_one.patch
  (git-fixes bsc#1224959 CVE-2021-47310).
- Update
  patches.suse/net-usb-kalmia-Don-t-pass-act_len-in-usb_bulk_msg-er.patch
  (git-fixes bsc#1225549 CVE-2023-52703).
- Update
  patches.suse/nfs-fix-acl-memory-leak-of-posix_acl_create.patch
  (git-fixes bsc#1225058 CVE-2021-47320).
- Update
  patches.suse/nfsd-fix-use-after-free-due-to-delegation-race.patch
  (git-fixes bsc#1225404 CVE-2021-47506).
- Update
  patches.suse/ocfs2-fix-data-corruption-after-conversion-from-inli.patch
  (bsc#1190795 bsc#1225251 CVE-2021-47460).
- Update
  patches.suse/ocfs2-mount-fails-with-buffer-overflow-in-strlen.patch
  (bsc#1197760 bsc#1225252 CVE-2021-47458).
- Update patches.suse/phy-mdio-fix-memory-leak.patch (git-fixes
  bsc#1225336 CVE-2021-47416).
- Update
  patches.suse/ppdev-Add-an-error-check-in-register_device.patch
  (git-fixes bsc#1225640 CVE-2024-36015).
- Update
  patches.suse/s390-dasd-protect-device-queue-against-concurrent-access.patch
  (git-fixes bsc#1217519 bsc#1225572 CVE-2023-52774).
- Update
  patches.suse/s390-qeth-fix-NULL-deref-in-qeth_clear_working_pool_list
  (git-fixes bsc#1225164 CVE-2021-47369).
- Update
  patches.suse/s390-qeth-fix-deadlock-during-failing-recovery
  (bsc#1206213 LTC#200742 bsc#1225207 CVE-2021-47382).
- Update
  patches.suse/scsi-core-Fix-bad-pointer-dereference-when-ehandler-kthread-is-invalid
  (git-fixes bsc#1224926 CVE-2021-47337).
- Update
  patches.suse/scsi-core-Put-LLD-module-refcnt-after-SCSI-device-is-released
  (git-fixes bsc#1225322 CVE-2021-47480).
- Update
  patches.suse/scsi-libfc-Fix-array-index-out-of-bound-exception.patch
  (bsc#1188616 bsc#1224963 CVE-2021-47308).
- Update
  patches.suse/scsi-mpt3sas-Fix-kernel-panic-during-drive-powercycle-test
  (git-fixes bsc#1225384 CVE-2021-47565).
- Update
  patches.suse/scsi-qla2xxx-Fix-a-memory-leak-in-an-error-path-of-qla2x00_process_els
  (git-fixes bsc#1225192 CVE-2021-47473).
- Update
  patches.suse/tipc-fix-a-possible-memleak-in-tipc_buf_append.patch
  (bsc#1221977 CVE-2021-47162 bsc#1225764 CVE-2024-36954).
- Update
  patches.suse/tracing-Correct-the-length-check-which-causes-memory-corruption.patch
  (git-fixes bsc#1224990 CVE-2021-47274).
- Update
  patches.suse/tracing-trigger-Fix-to-return-error-if-failed-to-alloc-snapshot.patch
  (git-fixes CVE-2024-26920).
- Update
  patches.suse/tty-n_gsm-require-CAP_NET_ADMIN-to-attach-N_GSM0710-.patch
  (bsc#1222619 CVE-2023-52880).
- Update
  patches.suse/tty-serial-8250-serial_cs-Fix-a-memory-leak-in-error.patch
  (git-fixes bsc#1225084 CVE-2021-47330).
- Update
  patches.suse/udf-Fix-NULL-pointer-dereference-in-udf_symlink-func.patch
  (bsc#1206646 bsc#1225128 CVE-2021-47353).
- Update
  patches.suse/usb-config-fix-iteration-issue-in-usb_get_bos_descri.patch
  (git-fixes bsc#1225092 CVE-2023-52781).
- Update
  patches.suse/usb-dwc2-check-return-value-after-calling-platform_g.patch
  (git-fixes bsc#1225330 CVE-2021-47409).
- Update
  patches.suse/usb-dwc3-ep0-fix-NULL-pointer-exception.patch
  (git-fixes bsc#1224996 CVE-2021-47269).
- Update patches.suse/usb-musb-dsps-Fix-the-probe-error-path.patch
  (git-fixes bsc#1225244 CVE-2021-47436).
- Update patches.suse/usbnet-sanity-check-for-maxpacket.patch
  (git-fixes bsc#1225351 CVE-2021-47495).
- Update
  patches.suse/watchdog-Fix-possible-use-after-free-by-calling-del_.patch
  (git-fixes bsc#1225060 CVE-2021-47321).
- Update
  patches.suse/watchdog-Fix-possible-use-after-free-in-wdt_startup.patch
  (git-fixes bsc#1225030 CVE-2021-47324).
- Update
  patches.suse/watchdog-sc520_wdt-Fix-possible-use-after-free-in-wd.patch
  (git-fixes bsc#1225026 CVE-2021-47323).
- Update
  patches.suse/wl1251-Fix-possible-buffer-overflow-in-wl1251_cmd_sc.patch
  (git-fixes bsc#1225177 CVE-2021-47347).
- commit 8975a47

- powerpc/pseries/lparcfg: drop error message from guest name
  lookup (bsc#1187716 ltc#193451 git-fixes).
- commit 62b0891

- blacklist.conf: PPC fsl_msi is not used
- commit bbad33b

- netfilter: nft_compat: explicitly reject ERROR and standard
  target (git-fixes).
- commit 46fdab6

- netfilter: x_tables: set module owner for icmp(6) matches
  (git-fixes).
- commit 8835e2a

- netfilter: nf_queue: augment nfqa_cfg_policy (git-fixes).
- commit d5734cd

- rds: avoid unenecessary cong_update in loop transport
  (git-fixes).
- commit 758da4a

- cls_rsvp: check user supplied offsets (CVE-2023-42755
  bsc#1215702).
- commit b722f7c

- l2tp: pass correct message length to ip6_append_data
  (git-fixes).
- commit 5edafdb

- net: 9p: avoid freeing uninit memory in p9pdu_vreadf
  (git-fixes).
- commit fdb6a12

- wifi: cfg80211: avoid leaking stack data into trace (git-fixes).
- commit 58724e2

- ipv4, ipv6: Fix handling of transhdrlen in
  __ip{,6}_append_data() (git-fixes).
- commit 7f0cb3d

- rxrpc: Fix a memory leak in rxkad_verify_response() (git-fixes).
- commit 301026e

- wifi: radiotap: fix kernel-doc notation warnings (git-fixes).
- commit a96badd

- net: tcp: fix unexcepted socket die when snd_wnd is 0
  (git-fixes).
- commit 66b602a

- tcp: tcp_make_synack() can be called from process context
  (git-fixes).
- commit 1171bb0

- net/smc: fix fallback failed while sendmsg with fastopen
  (git-fixes).
- commit 85612f4

- nfc: change order inside nfc_se_io error path (git-fixes).
- commit 92d40f5

- ila: do not generate empty messages in
  ila_xlat_nl_cmd_get_mapping() (git-fixes).
- commit bd4b08a

- rds: ib: Fix missing call to rds_ib_dev_put in rds_ib_setup_qp
  (git-fixes).
- commit 30e8bf8

- rxrpc: Work around usercopy check (git-fixes).
- commit f1a8d7a

- rxrpc: Don't put crypto buffers on the stack (git-fixes).
- commit d4118f5

- rxrpc: Provide a different lockdep key for call-&amp;gt;user_mutex
  for kernel calls (git-fixes).
- commit 256d44f

- rxrpc: The mutex lock returned by rxrpc_accept_call() needs
  releasing (git-fixes).
- commit 56d0a26

- net: atlantic: eliminate double free in error handling logic
  (CVE-2023-52664 bsc#1224747).
- ipvlan: add ipvlan_route_v6_outbound() helper (CVE-2023-52796
  bsc#1224930).
- net/mlx5e: Fix page reclaim for dead peer hairpin
  (CVE-2021-47246 bsc#1224831).
- commit e8481e2

- ceph: blocklist the kclient when receiving corrupted snap trace
  (bsc#1225222 CVE-2023-52732).
- commit afa0bf6

- btrfs: add missing mutex_unlock in btrfs_relocate_sys_chunks() (CVE-2024-35936 bsc#1224644)
- commit 7904756

- btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks() (CVE-2024-35936 bsc#1224644)
- commit 64d6920

- ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array (bsc#1225506 CVE-2021-47548)
- commit e4002ca

- mmc: sdhci-msm: pervent access to suspended controller (bsc#1225708 CVE-2024-36029)
- commit 0915583

- llc: call sock_orphan() at release time
  (CVE-2024-26625 bsc#1221086)
- commit 1715209

- blacklist.conf: not affected by CVE-2024-35984
- commit 19bc954

- virtio-net: Add validation for used length (CVE-2021-47352
  bsc#1225124).
- commit 91c03a8

- calipso: fix memory leak in netlbl_calipso_add_pass()
  (CVE-2023-52698 bsc#1224621)
- commit 008f52c

- blacklist.conf: Add c5b0a7eefc70 sched/fair: Remove sysctl_sched_migration_cost condition
- commit dbc3425

- ppdev: Add an error check in register_device (git-fixes).
- commit d524561

- drm/amdgpu: fix gart.bo pin_count leak (CVE-2021-47431 bsc#1225390).
- commit 1e38f4d

- btrfs: send: handle path ref underflow in header iterate_inode_ref() (CVE-2024-35935 bsc#1224645)
- commit 0b2d17e

- cifs: fix underflow in parse_server_interfaces() (bsc#1223084,
  CVE-2024-26828).
- commit 7164147

- drm/nouveau/debugfs: fix file release memory leak (CVE-2021-47423 bsc#1225366).
- commit 5f7b5c9

- drm/radeon: fix a possible null pointer dereference (CVE-2022-48710 bsc#1225230).
- commit ee59a3e

- nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells
  (bsc#1225355 CVE-2021-47497).
- commit 30121bc

- drm/vc4: don't check if plane-&amp;gt;state-&amp;gt;fb == state-&amp;gt;fb (CVE-2024-35932 bsc#1224650).
- commit 4fdcf5e

- iio: mma8452: Fix trigger reference couting (bsc#1225360
  CVE-2021-47500).
- commit a0d87d5

- PCI/PM: Drain runtime-idle callbacks before driver removal
  (CVE-2024-35809 bsc#1224738).
- commit 9f4d35b

- tty: Fix out-of-bound vmalloc access in imageblit
  (CVE-2021-47383 bsc#1225208).
- commit a21c750

- ALSA: pcm: oss: Fix negative period/buffer sizes (CVE-2021-47511
  bsc#1225411).
- commit 748d8c1

- ALSA: pcm: oss: Limit the period size to 16MB (CVE-2021-47509
  bsc#1225409).
- commit 8f92260

- x86/mm/pat: fix VM_PAT handling in COW mappings (bsc#1224525
  CVE-2024-35877).
- commit d228bf6

- batman-adv: Avoid infinite loop trying to resize local TT
  (CVE-2024-35982 bsc#1224566)
- commit 4f15041

- ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr
  (CVE-2024-35969 bsc#1224580)
- commit bcaf17a

- blacklist.conf: Add SPI fix commit to be ignored (CVE-2021-47469 bsc#1225347)
  SLE12-SP5 has no devm spi controller allocation, hence it's superfluous
- commit 939a6a5

- kABI workaround for spi_controller (CVE-2021-47469 bsc#1225347).
- commit af00c9b

- spi: Fix deadlock when adding SPI controllers on SPI buses
  (CVE-2021-47469 bsc#1225347).
- commit 575a8d4

- kvm: avoid speculation-based attacks from out-of-range memslot
  accesses (bsc#1224960, CVE-2021-47277).
- commit 7198007

- KVM: SVM: Flush pages under kvm-&amp;gt;lock to fix UAF in
  svm_register_enc_region() (bsc#1224725, CVE-2024-35791).
- commit 818a70e

- ipack: ipoctal: fix stack information leak (CVE-2021-47401
  bsc#1225242).
- commit 3e8997b

- drm/radeon: possible buffer overflow (CVE-2023-52867 bsc#1225009).
- commit 45094e6

- drm/panel: fix a possible null pointer dereference (CVE-2023-52821 bsc#1225022).
- commit 109e7f1

- RDMA: Verify port when creating flow rule (CVE-2021-47265 bsc#1224957)
- commit c0cbaec

- drm/amd/pm: Update intermediate power state for SI (CVE-2021-47362 bsc#1225153).
- commit 318c627

- mcb: fix error handling in mcb_alloc_bus() (CVE-2021-47361
  bsc#1225151).
- commit 813b8ac

- platform/x86: wmi: Fix opening of char device (CVE-2023-52864
  bsc#1225132).
- commit b207efb

- pinctrl: single: fix potential NULL dereference (CVE-2022-48708
  bsc#1224942).
- commit feac349

- VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()
  (CVE-2024-35944 bsc#1224648).
- commit a03c425

- net: ipv4: fix memory leak in ip_mc_add1_src
  (CVE-2021-47238 bsc#1224847)
- commit 4ce368a

- mmc: sdio: fix possible resource leaks in some error paths
  (CVE-2023-52730 bsc#1224956).
- commit 8629def

- atm: nicstar: Fix possible use-after-free in nicstar_cleanup()
  (CVE-2021-47355 bsc#1225141).
- commit 111c5b1

- netfilter: synproxy: Fix out of bounds when parsing TCP options
  (CVE-2021-47245 bsc#1224838)
- commit 3bf50df

- of: module: prevent NULL pointer dereference in vsnprintf()
  (CVE-2024-35878 bsc#1224671).
- commit dcde1a4

- IB/hfi1: Restore allocated resources on failed copyout (CVE-2023-52747 bsc#1224931)
- commit 4ba08d9

- net: rds: fix memory leak in rds_recvmsg
  (CVE-2021-47249 bsc#1224880)
- commit 79b2ee2

- sctp: break out if skb_header_pointer returns NULL in sctp_rcv_ootb
  (CVE-2021-47397 bsc#1225082)
- commit 2340710

- net: ipv4: fix memory leak in netlbl_cipsov4_add_std
  (CVE-2021-47250 bsc#1224827)
- commit ffd876f

- btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
  (CVE-2024-35849 bsc#1224733).
- commit 4e18545

- ring-buffer: Fix a race between readers and resize checks
  (bsc#1222893).
- commit e55a48c

- ASoC: tracing: Export SND_SOC_DAPM_DIR_OUT to its value
  (git-fixes).
- commit 56a4e35

- tracing: hide unused ftrace_event_id_fops (git-fixes).
- commit 6e3bbc9

- tracing: Fix blocked reader of snapshot buffer (git-fixes).
- commit 7cc9ae2

- ALSA: usb-audio: Stop parsing channels bits when all channels
  are found (CVE-2024-27436 bsc#1224803).
- ALSA: seq: Fix race of snd_seq_timer_open() (CVE-2021-47281
  bsc#1224983).
- commit 19aff08

- af_unix: annote lockless accesses to unix_tot_inflight &amp;amp; gc_in_progress (bsc#1223384).
- commit 8ee0966

- blacklist.conf: add not-needed or too intrusive tracing fixes
- commit ab535d8

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

- tracing: Use .flush() call to wake up readers (git-fixes).
- commit 4442cfe

- tracing: Use strncpy instead of memcpy when copying comm in
  trace.c (git-fixes).
- commit 77a5fe6

- ring-buffer: Clean ring_buffer_poll_wait() error return
  (git-fixes).
- commit dec7c48

- wifi: mac80211: check/clear fast rx for non-4addr sta VLAN
  changes (CVE-2024-35789 bsc#1224749).
- media: tc358743: register v4l2 async device only after
  successful setup (CVE-2024-35830 bsc#1224680).
- misc/libmasm/module: Fix two use after free in ibmasm_init_one
  (CVE-2021-47334 bsc#1225112).
- atm: iphase: fix possible use-after-free in ia_module_exit()
  (CVE-2021-47357 bsc#1225144).
- commit 4495db1

- clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data
  (CVE-2023-52875 bsc#1225096).
- commit eff8019

- clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data
  (CVE-2023-52865 bsc#1225086).
- commit c2dc4d3

- ax25: fix use-after-free bugs caused by ax25_ds_del_timer
  (CVE-2024-35887 bzg#1224663)
- commit 2bbaa4c

- regmap: Fix possible double-free in regcache_rbtree_exit()
  (CVE-2021-47483 bsc#1224907).
- commit 1f96a36

- s390/pci: fix max size calculation in zpci_memcpy_toio()
  (git-fixes bsc#1225062).
- commit 1d5a845

- s390/zcrypt: fix reference counting on zcrypt card objects
  (git-fixes CVE-2024-26957 bsc#1223666).
- commit 1a50d91

- KVM: s390: Check kvm pointer when testing KVM_CAP_S390_HPAGE_1M
  (git-fixes bsc#1225059).
- commit b5429fa

- Refresh
  patches.suse/USB-core-Fix-deadlock-in-usb_deauthorize_interface.patch.
- Update
  patches.suse/bpf-sockmap-Prevent-lock-inversion-deadlock-in-map-d.patch
  (bsc#1209657 CVE-2023-0160 CVE-2024-35895 bsc#1224511).
- Update
  patches.suse/nfsd-Fix-error-cleanup-path-in-nfsd_rename.patch
  (bsc#1221044 CVE-2023-52591 CVE-2024-35914 bsc#1224482).
- Update
  patches.suse/wifi-brcmfmac-Fix-use-after-free-bug-in-brcmf_cfg802.patch
  (CVE-2023-47233 bsc#1216702 CVE-2024-35811 bsc#1224592).
- commit 9a84305

- Update
  patches.suse/powerpc-powernv-Add-a-null-pointer-check-in-opal_eve.patch
  (bsc#1065729 CVE-2023-52686 bsc#1224682).
- Update
  patches.suse/powerpc-powernv-Add-a-null-pointer-check-in-opal_pow.patch
  (bsc#1181674 ltc#189159 git-fixes CVE-2023-52696 bsc#1224601).
- Update
  patches.suse/pstore-ram_core-fix-possible-overflow-in-persistent_ram_init_ecc.patch
  (git-fixes CVE-2023-52685 bsc#1224728).
- commit 0720a5d

- Update
  patches.suse/NFS-Fix-a-potential-NULL-dereference-in-nfs_get_clie.patch
  (git-fixes CVE-2021-47260 bsc#1224834).
- Update
  patches.suse/PCI-aardvark-Fix-kernel-panic-during-PIO-transfer.patch
  (git-fixes CVE-2021-47229 bsc#1224854).
- Update
  patches.suse/batman-adv-Avoid-WARN_ON-timing-related-checks.patch
  (git-fixes CVE-2021-47252 bsc#1224882).
- Update
  patches.suse/can-mcba_usb-fix-memory-leak-in-mcba_usb.patch
  (git-fixes CVE-2021-47231 bsc#1224849).
- Update
  patches.suse/gfs2-Fix-use-after-free-in-gfs2_glock_shrink_scan.patch
  (git-fixes CVE-2021-47254 bsc#1224888).
- Update
  patches.suse/media-ngene-Fix-out-of-bounds-bug-in-ngene_command_c.patch
  (git-fixes CVE-2021-47288 bsc#1224889).
- Update
  patches.suse/memory-fsl_ifc-fix-leak-of-IO-mapping-on-probe-failu.patch
  (git-fixes CVE-2021-47315 bsc#1224892).
- Update
  patches.suse/memory-fsl_ifc-fix-leak-of-private-memory-on-probe-f.patch
  (git-fixes CVE-2021-47314 bsc#1224893).
- Update patches.suse/net-cdc_eem-fix-tx-fixup-skb-leak.patch
  (git-fixes CVE-2021-47236 bsc#1224841).
- Update
  patches.suse/net-ethernet-fix-potential-use-after-free-in-ec_bhf_.patch
  (git-fixes CVE-2021-47235 bsc#1224844).
- Update
  patches.suse/net-hamradio-fix-memory-leak-in-mkiss_close.patch
  (git-fixes CVE-2021-47237 bsc#1224830).
- Update
  patches.suse/net-usb-fix-possible-use-after-free-in-smsc75xx_bind.patch
  (bsc#1221994 CVE-2021-47171 CVE-2021-47239 bsc#1224846).
- Update
  patches.suse/scsi-core-Fix-error-handling-of-scsi_host_alloc
  (git-fixes CVE-2021-47258 bsc#1224899).
- Update
  patches.suse/udp-fix-race-between-close-and-udp_abort.patch
  (git-fixes CVE-2021-47248 bsc#1224867).
- Update
  patches.suse/usb-dwc3-core-fix-kernel-panic-when-do-reboot.patch
  (git-fixes CVE-2021-47220 bsc#1224859).
- commit 7295d7f

- Update
  patches.suse/gfs2-Fix-use-after-free-in-gfs2_glock_shrink_scan.patch
  (git-fixes CVE-2021-47254).
- commit 38ebdb5

- blacklist.conf: pure cleanup
- commit 5f0720c

- blacklist.conf: we select the CONFIG whose absence triggers this in all
  configs
- commit 2c2df2e

- assoc_array: Fix BUG_ON during garbage collect.
- commit 56fe1ad

- list: fix a data-race around ep-&amp;gt;rdllist (git-fixes).
- commit f2db318

- lib/mpi: use kcalloc in mpi_resize (git-fixes).
- commit c463c57

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

- drm/amd/pm: fix a double-free in si_dpm_init (CVE-2023-52691 bsc#1224607).
- commit 7a87ede

- Fix backport of :  NFS: Fix error handling for O_DIRECT write
  scheduling (bsc#1224785).
- commit e968faa

- blacklist.conf: Add a1fd0b9d751f sched/fair: Allow disabling sched_balance_newidle with sched_relax_domain_level
- commit 3567984

- rpm/kernel-obs-build.spec.in: remove reiserfs from OBS initrd
  We disabled the FS in bug 1202309. And we actively blacklist it in:
  /usr/lib/modprobe.d/60-blacklist_fs-reiserfs.conf
  This, as a side-effect, fixes obs-build's warning:
  dracut-pre-udev[1463]: sh: line 1: /usr/lib/module-init-tools/unblacklist: No such file or directory
  Exactly due to the above 60-blacklist_fs-reiserfs.conf trying to call the
  above unblacklist.
  We should likely drop ext2+ext3 from the list too, as we don't build
  them at all. But that's a different story.
- commit 9e1a078

- Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout
  (bsc#1224174 CVE-2024-27398).
- commit 231873b

- af_unix: Fix garbage collector racing against connect()
  (CVE-2024-26923 bsc#1223384).
- af_unix: Replace BUG_ON() with WARN_ON_ONCE() (bsc#1223384).
- af_unix: Do not use atomic ops for unix_sk(sk)-&amp;gt;inflight (bsc#1223384).
- commit d9e2f79

- blacklist.conf: btrfs: config fix for 256k pages
- commit a9a21e4

- btrfs: validate qgroup inherit for SNAP_CREATE_V2 ioctl (git-fixes)
- commit db54449

- btrfs: tree-checker: do not error out if extent ref hash doesn't match (git-fixes)
- commit 874e705

- btrfs: send: ensure send_fd is writable (git-fixes)
- commit 7e0fb05

- btrfs: send: limit number of clones and allocated memory size (git-fixes)
- commit fa2504c

- btrfs: fail mount when sb flag is not in BTRFS_SUPER_FLAG_SUPP (git-fixes)
- commit 7f9b413

- blacklist.conf: btrfs: metadata dump v2 definition only
  e2731e55884f2138a252b0a3d7b24d57e49c3c59
- commit b680815

- btrfs: Fix out of bounds access in btrfs_search_slot (git-fixes)
- commit 6b6da17

- btrfs: fix deadlock when writing out space cache (git-fixes)
- commit cdd0586

- btrfs: Explicitly handle btrfs_update_root failure (git-fixes)
- commit ac502aa

- btrfs: undo writable superblocke when sprouting fails (git-fixes)
- commit 9fbf261

- btrfs: avoid null pointer dereference on fs_info when calling btrfs_crit (git-fixes)
- commit daf7dc2

- drm/msm/dpu: Add mutex lock in control vblank irq (CVE-2023-52586 bsc#1221081).
- commit 474c511

- btrfs: prevent to set invalid default subvolid (git-fixes)
- commit c399d80

- Btrfs: fix incorrect {node,sector}size endianness from BTRFS_IOC_FS_INFO (git-fixes)
- commit b016cd3

- Refresh patches.suse/nfs-fix-UAF-in-direct-writes.patch.
  Fixup the build warning:
  Changed build warnings:
  * **** 1 warnings *****
  * passing argument 1 of 'nfs_commit_end' from incompatible pointer type [enabled by default] (nfs_commit_end) in ../fs/nfs/direct.c in nfs_direct_commit_complete
  ../fs/nfs/direct.c: In function 'nfs_direct_commit_complete':
  ../fs/nfs/direct.c:668:2: warning: passing argument 1 of 'nfs_commit_end' from incompatible pointer type [enabled by default]
- commit 10952b2

- Update
  patches.suse/USB-core-Fix-deadlock-in-usb_deauthorize_interface.patch
  (git-fixes CVE-2024-26934 bsc#1223671).
- commit cc5c596

- s390/cpum_cf: make crypto counters upward compatible across
  machine types (bsc#1224347).
- commit 8af04c2

- scsi: mpt3sas: Fix loop logic (git-fixes).
- scsi: snic: Fix double free in snic_tgt_create() (git-fixes).
- commit d29fa2d

- ecryptfs: fix kernel panic with null dev_name (git-fixes)
- commit 4ecd122

- ecryptfs: Fix typo in message (git-fixes)
- commit b1331d9

- ep_create_wakeup_source(): dentry name can change under you (git-fixes)
- commit e90f9bb

- ecryptfs: fix a memory leak bug in ecryptfs_init_messaging() (git-fixes)
- commit 7163ecf

- ecryptfs: fix a memory leak bug in parse_tag_1_packet() (git-fixes)
- commit d3aeb95

- exportfs_decode_fh(): negative pinned may become positive without the parent locked (git-fixes)
- commit 681e816

- autofs: fix a leak in autofs_expire_indirect() (git-fixes)
- commit 2e9a485

- fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes (git-fixes)
- commit 73af5d9

- blacklist.conf: fs: fget/fput optimization
  Commit looks safe but is not a fix rather than an optimization.
- commit 2263087

- fscrypt: clean up some BUG_ON()s in block encryption/decryption (git-fixes)
- commit 2945a7c

- blacklist.conf: fscrypt: depends on no-key format update
  Fix depends on functionality added by edc440e3d27fb3 (&amp;quot;fscrypt: improve
  format of no-key names&amp;quot;)
- commit 871959c

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

- blacklist.conf: orangefs not supported
- commit f732788

- nouveau: fix instmem race condition around ptr stores (bsc#1223633 CVE-2024-26984)
- commit 9350c2a

- Refresh
  patches.suse/x86-boot-Ignore-relocations-in-.notes-sections-in-walk_rel.patch.
- commit 1389ef9

- net: usb: smsc95xx: stop lying about skb-&amp;gt;truesize (git-fixes).
- commit 3b70647

- net: usb: sr9700: stop lying about skb-&amp;gt;truesize (git-fixes).
- commit d83f5a1

- usb: aqc111: stop lying about skb-&amp;gt;truesize (git-fixes).
- commit 0a7bdae

- Fix use-before-set in hand-coded part of patch
  Refresh:
  - patches.suse/scsi-iscsi_tcp-restrict-to-TCP-sockets.patch.
- commit 757fd5b

- Fix build warning about now-unused function
  Refresh:
  - patches.suse/scsi-libsas-Fix-disk-not-being-scanned-in-after-being-removed.patch
- commit bbcdd67

- Refresh
  patches.suse/media-flexcop-usb-fix-NULL-ptr-deref-in-flexcop_usb_.patch.
  Fix the Patch-mainline tag.
- commit 3169adb

- Bluetooth: btusb: Some Qualcomm Bluetooth adapters stop working
  (git-fixes).
- commit 23ff40d

- usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear
  (bsc#1220487 CVE-2021-46933).
- commit 33d6865

- blacklist.conf: Add 9474c62ab65f net/sched: Add module alias for sch_fq_pie
- commit b755821

- net: gtp: Fix Use-After-Free in gtp_dellink (bsc#1224096
  CVE-2024-27396).
- commit a81f04c

- blacklist.conf: add commits for some git-fixes to be skipped
- commit c8e9217

- scsi: qla2xxx: Fix off by one in qla_edif_app_getstats()
  (git-fixes).
- scsi: lpfc: Correct size for wqe for memset() (git-fixes).
- scsi: libsas: Fix disk not being scanned in after being removed
  (git-fixes).
- scsi: libsas: Add a helper sas_get_sas_addr_and_dev_type()
  (git-fixes).
- scsi: bfa: Fix function pointer type mismatch for hcb_qe-&amp;gt;cbfn
  (git-fixes).
- scsi: csiostor: Avoid function pointer casts (git-fixes).
- scsi: isci: Fix an error code problem in isci_io_request_build()
  (git-fixes).
- scsi: bnx2fc: Fix skb double free in bnx2fc_rcv() (git-fixes).
- scsi: be2iscsi: Fix a memleak in beiscsi_init_wrb_handle()
  (git-fixes).
- scsi: megaraid_sas: Increase register read retry rount from
  3 to 30 for selected registers (git-fixes).
- scsi: libfc: Fix potential NULL pointer dereference in
  fc_lport_ptp_setup() (git-fixes).
- scsi: mpt3sas: Fix in error path (git-fixes).
- scsi: iscsi_tcp: restrict to TCP sockets (git-fixes).
- scsi: lpfc: Fix the NULL vs IS_ERR() bug for
  debugfs_create_file() (git-fixes).
- scsi: mpt3sas: Perform additional retries if doorbell read
  returns 0 (git-fixes).
- scsi: qedf: Do not touch __user pointer in
  qedf_dbg_fp_int_cmd_read() directly (git-fixes).
- scsi: qedf: Do not touch __user pointer in
  qedf_dbg_debug_cmd_read() directly (git-fixes).
- scsi: qedf: Do not touch __user pointer in
  qedf_dbg_stop_io_on_error_cmd_read() directly (git-fixes).
- scsi: qla4xxx: Add length check when parsing nlattrs
  (git-fixes).
- scsi: be2iscsi: Add length check when parsing nlattrs
  (git-fixes).
- scsi: iscsi: Add strlen() check in iscsi_if_set{_host}_param()
  (git-fixes).
- scsi: iscsi: Add length check for nlattr payload (git-fixes).
- scsi: qedf: Fix firmware halt over suspend and resume
  (git-fixes).
- scsi: qedi: Fix firmware halt over suspend and resume
  (git-fixes).
- scsi: qedi: Fix potential deadlock on &amp;amp;qedi_percpu-&amp;gt;p_work_lock
  (git-fixes).
- scsi: snic: Fix possible memory leak if device_add() fails
  (git-fixes).
- scsi: core: Fix possible memory leak if device_add() fails
  (git-fixes).
- scsi: core: Fix legacy /proc parsing buffer overflow
  (git-fixes).
- scsi: 53c700: Check that command slot is not NULL (git-fixes).
- scsi: 3w-xxxx: Add error handling for initialization failure
  in tw_probe() (git-fixes).
- scsi: lpfc: Fix double free in lpfc_cmpl_els_logo_acc() caused
  by lpfc_nlp_not_used() (git-fixes).
- scsi: qedf: Fix NULL dereference in error handling (git-fixes).
- scsi: stex: Fix gcc 13 warnings (git-fixes).
- scsi: core: Decrease scsi_device's iorequest_cnt if dispatch
  failed (git-fixes).
- commit 43436ef

- Update
  patches.suse/net-usb-fix-possible-use-after-free-in-smsc75xx_bind.patch
  (bsc#1221994 CVE-2021-47171).
  Added bugzilla ID and CVE
  The initial fix was present, but it turned later out to be wrong
  and the correct fix lacked the references.
- commit cf80be9

- usb: aqc111: check packet for fixup for true limit (bsc#1217169
  CVE-2023-52655).
- commit 9dd6dfa

- btrfs: sysfs: use NOFS for device creation (git-fixes)
  Adjustment: add #include
- commit f20ad81

- btrfs: send: in case of IO error log it (git-fixes)
- commit 840f907

- btrfs: fix lost error handling when looking up extended ref on log replay (git-fixes)
- commit 20591f1

- btrfs: check if root is readonly while setting security xattr (git-fixes)
- commit 01674b5

- btrfs: limit device extents to the device size (git-fixes)
- commit 0ba992a

- btrfs: fix btrfs_prev_leaf() to not return the same key twice (git-fixes)
- commit 2834caf

- btrfs: fix range_end calculation in extent_write_locked_range (git-fixes)
- commit e723a0b

- btrfs: scrub: reject unsupported scrub flags (git-fixes)
- commit c5866de

- btrfs: fix race when deleting quota root from the dirty cow roots list (git-fixes)
- commit 1e8a661

- btrfs: fix lockdep splat and potential deadlock after failure running delayed items (git-fixes)
- commit 20fccdb

- btrfs: record delayed inode root in transaction (git-fixes)
- commit 7a64f13

- btrfs: tree-checker: fix inline ref size in error messages (git-fixes)
- commit 7031a61

- btrfs: don't stop integrity writeback too early (git-fixes)
- commit 9304b5f

- md: fix kmemleak of rdev-&amp;gt;serial (CVE-2024-26900, bsc#1223046).
- commit 0488367

- firewire: nosy: ensure user_length is taken into account when
  fetching packet contents (CVE-2024-27401 bsc#1224181).
- commit f890e6b

- aoe: avoid potential deadlock at set_capacity (CVE-2024-26775,
  bsc#1222627).
- commit 72683cd

- Update
  patches.suse/scsi-ufs-core-Improve-SCSI-abort-handling.patch
  (bsc#1222671, CVE-2021-47188).
- commit df1a16c

- blacklist.conf: pure cleanup
- commit b459965

- blacklist.conf: irrelevant in our configs
- commit 91ec532

- blacklist.conf: pure cleanup
- commit 4da5c7c

- blacklist.conf: pure cleanup
- commit c4855e9

- blacklist.conf: pure cleanup
- commit 00ca6d9

- blacklist.conf: pure cleanup
- commit a6aa054

- blacklist.conf: pure cleanup
- commit 27ba46a

- nfs: fix UAF in direct writes (bsc#1223653 CVE-2024-26958).
- commit 5347d82

- scsi: libsas: Introduce struct smp_disc_resp (git-fixes).
- commit 5fefdbb

- drm/radeon: add a force flush to delay work when radeon (bsc#1223932 CVE-2022-48704)
- commit 05d207f

- blacklist.conf: Append 'drm/amd/display: Fix MST Null Ptr for RV'
- commit aab0541

- btrfs: don't get an EINTR during drop_snapshot for reloc (git-fixes)
- commit 2f0ddbd

- btrfs: tree-checker: add missing returns after data_ref alignment checks (git-fixes)
- commit 465da04

- btrfs: tree-checker: add missing return after error in root_item (git-fixes)
- commit 2c66867

- btrfs: fix return value mixup in btrfs_get_extent (git-fixes)
- commit c7aefc2

- btrfs: tree-checker: Fix misleading group system information (git-fixes)
- Refresh patches.suse/0014-btrfs-tree-checker-get-fs_info-from-eb-in-block_grou.patch.
- commit 4c1912f

- btrfs: defrag: use btrfs_mod_outstanding_extents in cluster_pages_for_defrag (git-fixes)
- commit 6b856de

- btrfs: fix unaligned access in readdir (git-fixes)
- Refresh patches.suse/btrfs-support-swap-files.patch.
  Diff context only.
- commit 0df1b83

- btrfs: Fix NULL pointer exception in find_bio_stripe (git-fixes)
- commit 99eebfb

- net: vmxnet3: Fix NULL pointer dereference in
  vmxnet3_rq_rx_complete() (bsc#1223360).
- commit 829bff3

- usb: host: ohci-tmio: check return value after calling
  platform_get_resource() (bsc#1222894 CVE-2021-47206).
- blacklist.conf: blacklist entry was a mistake caused by the driver
  being dropped upstream, but only after SLE12
- commit 740a25a

- drm/amdgpu: Reset IH OVERFLOW_CLEAR bit (bsc#1223207 CVE-2024-26915)
- commit f1d8ff2

- Update
  patches.suse/USB-usb-storage-Prevent-divide-by-0-error-in-isd200_.patch
  (bsc#1223738 CVE-2024-27059).
  Added CVE and bugzilla ids
- commit 6bf9f21

- usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb
  ep transport error (bsc#1223752 CVE-2024-26996).
- commit f8904de

- drm/mediatek: Fix a null pointer crash in (CVE-2024-26874 bsc#1223048)
- commit e57c0ce

- ALSA: emu10k1: Fix out of bounds access in
  snd_emu10k1_pcm_channel_alloc() (bsc#1223923 CVE-2022-48702).
- commit af9ea5f

- of: fdt: fix off-by-one error in unflatten_dt_nodes()
  (CVE-2022-48672 bsc#1223931).
- commit 032891a

- inet: read sk-&amp;gt;sk_family once in inet_recv_error() (bsc#1222385
  CVE-2024-26679).
- commit 5c9ee90

- btrfs: abort in rename_exchange if we fail to insert the second ref (CVE-2021-47113 bsc#1221543)
- Refresh patches.suse/btrfs-prevent-rename2-from-exchanging-a-subvol-with-a-directory-from-different-parents.patch.
- commit 6cc4490

- btrfs: dev-replace: properly validate device names (CVE-2024-26791 bsc#1222793)
- commit cc0f00b

- Update
  patches.suse/net-sched-act_mirred-don-t-override-retval-if-we-alr.patch
  references (CVE-2024-26739 bsc#1222559, drop incorrect references).
- commit ea93ecf

- net/tls: Remove the context from the list in tls_device_down
  (bsc#1221545).
- commit 58c1b25

- tls: Fix context leak on tls_device_down (bsc#1221545).
- commit 389808e

- blacklist.conf: add 94ce3b64c62d
  Blacklist commit 94ce3b64c62d (&amp;quot;net/tls: Use RCU API to access
  tls_ctx-&amp;gt;netdev&amp;quot;). This is a follow-up to c55dcdd435aa which addresses an
  issue which is rather theoretical and the backport would be quite
  intrusive.
- commit 8ca558a

- ALSA: usb-audio: Fix an out-of-bounds bug in
  __snd_usb_parse_audio_interface() (CVE-2022-48701 bsc#1223921).
- commit 6f798e9

- kabi: hide new member of struct tls_context (CVE-2021-47131
  bsc#1221545).
- net/tls: Fix use-after-free after the TLS device goes down
  and up (CVE-2021-47131 bsc#1221545).
- commit 8c186be

- Update
  patches.suse/SUNRPC-fix-some-memleaks-in-gssx_dec_option_array.patch
  (git-fixes CVE-2024-27388 bsc#1223744).
- Update
  patches.suse/s390-Once-the-discipline-is-associated-with-the-device-de.patch
  (bsc#1141539 git-fixes CVE-2024-27054 bsc#1223819).
- Update
  patches.suse/scsi-qla2xxx-Fix-command-flush-on-cable-pull.patch
  (bsc1221816 CVE-2024-26931 bsc#1223627).
- Update patches.suse/scsi-qla2xxx-Fix-double-free-of-fcport.patch
  (bsc1221816 CVE-2024-26929 bsc#1223715).
- Update
  patches.suse/scsi-qla2xxx-Fix-double-free-of-the-ha-vp_map-pointe.patch
  (bsc1221816 CVE-2024-26930 bsc#1223626).
- commit daf9a87

- Update
  patches.suse/SUNRPC-fix-a-memleak-in-gss_import_v2_context.patch
  (git-fixes CVE-2023-52653 bsc#1223712).
- Update patches.suse/aio-fix-mremap-after-fork-null-deref.patch
  (git-fixes CVE-2023-52646 bsc#1223432).
- commit 793a07e

- Update
  patches.suse/i40e-Fix-kernel-crash-during-module-removal.patch
  (git-fixes CVE-2022-48688 bsc#1223953).
- Update
  patches.suse/ipv6-sr-fix-out-of-bounds-read-when-setting-HMAC-dat.patch
  (bsc#1211592 CVE-2023-2860 CVE-2022-48687 bsc#1223952).
- Update
  patches.suse/s390-dasd-fix-Oops-in-dasd_alias_get_start_dev-due-to-missing-pavgroup
  (git-fixes CVE-2022-48636 bsc#1223512).
- Update
  patches.suse/scsi-mpt3sas-Fix-use-after-free-warning.patch
  (git-fixes CVE-2022-48695 bsc#1223941).
- Update
  patches.suse/scsi-qla2xxx-Fix-memory-leak-in-__qlt_24xx_handle_ab.patch
  (bsc#1203935 CVE-2022-48650 bsc#1223509).
- commit cc68904

- Update
  patches.suse/net-dsa-fix-a-crash-if-get_sset_count-fails.patch
  (CVE-2021-47146 bsc#1221979 CVE-2021-47159 bsc#1221967).
- Update
  patches.suse/scsi-ufs-core-Improve-SCSI-abort-handling.patch
  (bsc#11222671 CVE-2021-47188 bsc#1222671).
- commit 5a613f4

- Fix references of
  patches.suse/net-dsa-fix-a-crash-if-get_sset_count-fails.patch
  This fix actually refers to different CVE and bug report. Fix the error.
- commit b797fc2

- openvswitch: fix stack OOB read while fragmenting IPv4 packets
  (CVE-2021-46955 bsc#1220513).
- commit 1116e19

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

- Update
  patches.suse/SUNRPC-fix-some-memleaks-in-gssx_dec_option_array.patch
  (git-fixes CVE-2024-27388 bsc#1223744).
- Update
  patches.suse/s390-Once-the-discipline-is-associated-with-the-device-de.patch
  (bsc#1141539 git-fixes CVE-2024-27054 bsc#1223819).
- Update
  patches.suse/scsi-qla2xxx-Fix-command-flush-on-cable-pull.patch
  (bsc1221816 CVE-2024-26931 bsc#1223627).
- Update patches.suse/scsi-qla2xxx-Fix-double-free-of-fcport.patch
  (bsc1221816 CVE-2024-26929 bsc#1223715).
- Update
  patches.suse/scsi-qla2xxx-Fix-double-free-of-the-ha-vp_map-pointe.patch
  (bsc1221816 CVE-2024-26930 bsc#1223626).
- commit d54495e

- Update
  patches.suse/SUNRPC-fix-a-memleak-in-gss_import_v2_context.patch
  (git-fixes CVE-2023-52653 bsc#1223712).
- Update patches.suse/aio-fix-mremap-after-fork-null-deref.patch
  (git-fixes CVE-2023-52646 bsc#1223432).
- commit 6164312

- Update
  patches.suse/s390-dasd-fix-Oops-in-dasd_alias_get_start_dev-due-to-missing-pavgroup
  (git-fixes CVE-2022-48636 bsc#1223512).
- Update
  patches.suse/scsi-qla2xxx-Fix-memory-leak-in-__qlt_24xx_handle_ab.patch
  (bsc#1203935 CVE-2022-48650 bsc#1223509).
- commit b81c322

- drm/tegra: dsi: Add missing check for of_find_device_by_node (CVE-2023-52650 bsc#1223770)
- commit 52453b3

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

- printk: Update @console_may_schedule in
  console_trylock_spinning() (bsc#1223969).
- commit 2217d14

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

- drm: nv04: Fix out of bounds access (CVE-2024-27008 bsc#1223802).
- commit d2971e3

- usb: dwc2: Fix memory leak in dwc2_hcd_init.
- commit b68c644

- printk: Disable passing console lock owner completely during
  panic() (bsc#1197894).
- commit 7493ac1

- Input: ipaq-micro-keys - add error handling for devm_kmemdup.
- commit 8755dbb

- Input: xpad - add PXN V900 support.
- commit fbd5f3f

- Input: adxl34x - do not hardcode interrupt trigger type
  (git-fixes).
- commit 926a03d

- blacklist.conf: cleanup surpressing a warning
- commit 922f659

- Input: drv260x - sleep between polling GO bit (git-fixes).
- commit e9e8d04

- blacklist.conf: cleanup, not a fix, no code change
- commit 9cb5758

- blacklist.conf: driver not compiled
- commit a3fa3df

- blacklist.conf: driver not compiled
- commit 9dfacec

- blacklist.conf: driver not compiled
- commit 1aef6fe

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

- blacklist.conf: this patch enables features only
- commit b3e7c52

- blacklist.conf: false positive
- commit 88b62ef

- USB: core: Fix deadlock in usb_deauthorize_interface().
- commit ab56ab9

- USB: usb-storage: Prevent divide-by-0 error in
  isd200_ata_command (git-fixes).
- commit f114b54

- usb: roles: don't get/set_role() when usb_role_switch is
  unregistered.
- commit d121124

- usb: mon: Fix atomicity violation in mon_bin_vma_fault
  (git-fixes).
- commit 0605a2c

- blacklist.conf: not enabled
- commit 7aaa582

- blacklist.conf: kABI
- commit d241153

- drivers: usb: host: Fix deadlock in oxu_bus_suspend()
  (git-fixes).
- commit 4bfa035

- blacklist.conf: add two fuse commits from git-fixes
- commit 57c7ed8

- fuse: don't unhash root (bsc#1223954).
- commit 4838661

- tun: limit printing rate when illegal packet received by tun
  dev (bsc#1223745 CVE-2024-27013).
- net/mlx5e: Prevent deadlock while disabling aRFS (bsc#1223735
  CVE-2024-27014).
- nfp: flower: handle acti_netdevs allocation failure (bsc#1223827
  CVE-2024-27046).
- commit bb18705

- tipc: fix a possible memleak in tipc_buf_append (bsc#1221977
  CVE-2021-47162).
- commit 503e448

- media: usbtv: Remove useless locks in usbtv_video_free()
  (CVE-2024-27072 bsc#1223837).
- commit 784e536

- media: dvb-frontends: avoid stack overflow warnings with clang
  (CVE-2024-27075 bsc#1223842).
- commit 134dc5e

- media: ttpci: fix two memleaks in budget_av_attach
  (CVE-2024-27073 bsc#1223843).
- commit 13b28d2

- media: go7007: fix a memleak in go7007_load_encoder
  (CVE-2024-27074 bsc#1223844).
- commit 54185dc

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

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

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

- media: v4l2-tpg: fix some memleaks in tpg_alloc (CVE-2024-27078
  bsc#1223781).
- commit 9ec09ea

- tty/sysrq: replace smp_processor_id() with get_cpu()
  (bsc#1223540).
- commit f6b8019

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

- scsi: ufs: core: Improve SCSI abort handling (bsc#11222671,
  CVE-2021-47188).
- blacklist.conf: remove 3ff1f6b
- commit 9ba0cd1

- drm/bridge: adv7511: fix crash on irq during probe (CVE-2024-26876 bsc#1223119).
- commit be1e389

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

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

- cachefiles: fix memory leak in cachefiles_add_cache()
  (bsc#1222976 CVE-2024-26840).
- commit 7ab2bde

- net/bnx2x: Prevent access to a freed page in page_pool
  (bsc#1223049 CVE-2024-26859).
- commit d2c8d25

- spi: spi-fsl-dspi: Fix a resource leak in an error handling path
  (CVE-2021-47161 bsc#1221966).
- commit 86c2723

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

- blacklist.conf: Append 'drm/amdgpu: fix use-after-free bug'
- commit f438d4d

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

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

- net: fujitsu: fix potential null-ptr-deref (bsc#1221972
  CVE-2021-47149).
- commit 9abeb19

- tipc: skb_linearize the head skb when reassembling msgs
  (bsc#1221977 CVE-2021-47162).
- commit ba440f6

- net: dsa: fix a crash if -&amp;gt;get_sset_count() fails
  (CVE-2021-47146 bsc#1221979).
- commit 599796c

- mld: fix panic in mld_newpack() (CVE-2021-47146 bsc#1221979).
- commit e3d5602

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

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

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

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

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

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

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

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

- net: ice: Fix potential NULL pointer dereference in
  ice_bridge_setlink() (bsc#1223051 CVE-2024-26855).
- geneve: make sure to pull inner header in geneve_rx()
  (bsc#1223058 CVE-2024-26857).
- ppp_async: limit MRU to 64K (bsc#1222379 CVE-2024-26675).
- ipvlan: Fix out-of-bound bugs caused by unset skb-&amp;gt;mac_header
  (bsc#1223513 CVE-2022-48651).
- commit bc8fe89

- RDMA/mlx5: Fix fortify source warning while accessing Eth segment (bsc#1223203 CVE-2024-26907)
- commit 1c532b6

- regmap: prevent noinc writes from clobbering cache (bsc#1221162
  CVE-2023-52488).
- regmap: fix page selection for noinc writes (bsc#1221162
  CVE-2023-52488).
- regmap: fix page selection for noinc reads (bsc#1221162
  CVE-2023-52488).
- commit dc5bde0

- blacklist.conf: false positive
- commit 17b05a2

- usb: dwc2: check return value after calling
  platform_get_resource() (git-fixes).
- commit 831627d

- usb: dwc3: gadget: Ignore EP queue requests during bus reset
  (git-fixes).
- commit 270950d

- drm/amdgpu: validate the parameters of bo mapping operations more (CVE-2024-26922 bsc#1223315)
- commit 1a7d0fd

- ipvs: Fix checksumming on GSO of SCTP packets (bsc#1221958)
- commit 5e792b9

- i40e: Fix NULL ptr dereference on VSI filter sync (bsc#1222666
  CVE-2021-47184).
- commit 1ad3e1d

- usb: gadget: Fix issue with config_ep_by_speed function
  (git-fixes).
- commit e3f4200

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

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

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

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

- Update
  patches.suse/Bluetooth-rfcomm-Fix-null-ptr-deref-in-rfcomm_check_-2535b848.patch
  (bsc#1219170 CVE-2024-22099 CVE-2024-26903 bsc#1223187).
- Update
  patches.suse/aoe-fix-the-potential-use-after-free-problem-in-aoec.patch
  (bsc#1218562 CVE-2023-6270 CVE-2024-26898 bsc#1223016).
- Update
  patches.suse/net-sched-act_mirred-don-t-override-retval-if-we-alr.patch
  (CVE-2024-26733 bsc#1222585 CVE-2024-26739 bsc#1222559).
- Update
  patches.suse/sr9800-Add-check-for-usbnet_get_endpoints.patch
  (git-fixes CVE-2024-26651 bsc#1221337).
- commit f0c3935

- Update
  patches.suse/msft-hv-2480-x86-hyperv-Fix-NULL-deref-in-set_hv_tscchange_cb-if-.patch
  (git-fixes CVE-2021-47217 bsc#1222836).
- Update
  patches.suse/net-dpaa2-eth-fix-use-after-free-in-dpaa2_eth_remove.patch
  (git-fixes CVE-2021-47204 bsc#1222787).
- Update patches.suse/scsi-advansys-Fix-kernel-pointer-leak.patch
  (git-fixes CVE-2021-47216 bsc#1222876).
- Update
  patches.suse/scsi-lpfc-Fix-use-after-free-in-lpfc_unreg_rpi-routi.patch
  (bsc#1192145 CVE-2021-47198 bsc#1222883).
- commit 1aa3f8e

- bpf: Fix stackmap overflow check on 32-bit arches (bsc#1223035
  CVE-2024-26883).
- bpf: Fix hashtab overflow check on 32-bit arches (bsc#1223189
  CVE-2024-26884).
- bpf: Check for integer overflow when using roundup_pow_of_two()
  (bsc#1223035 CVE-2024-26883).
- commit 4249641

- IB/hfi1: Fix a memleak in init_credit_return (CVE-2024-26839 bsc#1222975)
- commit 1b9aeec

- Refresh
  patches.suse/NFS-add-atomic_open-for-NFSv3-to-handle-O_TRUNC-corr.patch.
  Handle too-long file names.
- commit d3b61d6

- wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is
  disabled (CVE-2023-52644 bsc#1222961).
- commit 411fc96

- clk: sunxi-ng: Unregister clocks/resets when unbinding
  (CVE-2021-47205 bsc#1222888).
- commit 67523b6

- ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
  (CVE-2021-47211 bsc#1222869).
- commit a86f817

- Update
  patches.suse/scsi-lpfc-Fix-list_add-corruption-in-lpfc_drain_txq.patch
  (bsc#1190576 CVE-2021-47203 bsc#1222881).
- commit 2cb2a3c

- ALSA: gus: fix null pointer dereference on pointer block
  (CVE-2021-47207 bsc#1222790).
- commit 2c3256c

- wifi: mac80211: fix race condition on enabling fast-xmit
  (CVE-2024-26779 bsc#1222772).
- commit 5e02fca

- wifi: rt2x00: restart beacon queue when hardware reset
  (CVE-2023-52595 bsc#1221046).
- commit 671852b

- ceph: prevent use-after-free in encode_cap_msg() (bsc#1222503
  CVE-2024-26689).
- commit 09813ff

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

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

- kABI: regmap: Add regmap_noinc_read/write API (bsc#1221162
  CVE-2023-52488).
- commit fb0c9d2

- regmap: Add regmap_noinc_write API (bsc#1221162 CVE-2023-52488).
- regmap: Add regmap_noinc_read API (bsc#1221162 CVE-2023-52488).
- commit 60efad2

- usb: roles: fix NULL pointer issue when put module's reference
  (bsc#1222609 CVE-2024-26747).
- commit 73af327

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

- Refresh patches.kabi/cpufeatures-kabi-fix.patch (bsc#1222952)
  Don't call set_cpu_caps when calling set_cpu_bug, this causes problems
  with overlapping feature/bug ints. Directly call set_bit witht he
  correct parameters.
- commit 16e52e8

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

- ext4: avoid allocating blocks from corrupted group in
  ext4_mb_try_best_found() (bsc#1222618 CVE-2024-26773).
- commit 4110538

- thermal: Fix NULL pointer dereferences in of_thermal_ functions (CVE-2021-47202 bsc#1222878)
- commit 08cf92c

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

- fbdev: sis: Error out if pixclock equals zero (bsc#1222765 CVE-2024-26777)
- commit 283e632

- fbdev: savage: Error out if pixclock equals zero (bsc#1222770 CVE-2024-26778)
- commit c2c54cf

- drm: Don't unref the same fb many times by mistake due to deadlock handling (CVE-2023-52486 bsc#1221277).
- commit 5843530

- blacklist.conf: add one more PCI git-fixes
- commit 7baca5d

- IB/ipoib: Fix mcast list locking (CVE-2023-52587 bsc#1221082)
- commit 94cde16

- RDMA/IPoIB: Fix error code return in ipoib_mcast_join (bsc#1221082)
- commit 348c98c

- RDMA/srp: Do not call scsi_done() from srp_abort() (CVE-2023-52515 bsc#1221048)
- commit d5d3a97

- RDMA/qedr: Fix qedr_create_user_qp error flow (bsc#1222677 CVE-2024-26743)
- commit c49697b

- RDMA/srpt: Support specifying the srpt_service_guid parameter (bsc#1222449 CVE-2024-26744)
- commit 00d0add

- NFS: avoid spurious warning of lost lock that is being unlocked
  (bsc#1221791).
- commit 63a2e3f

- Update
  patches.suse/NFS-add-atomic_open-for-NFSv3-to-handle-O_TRUNC-corr.patch
  (bsc#1219847 bsc#1221862).
  Fix a NULL-pointer-deref bug.  Make the patch closer to the patch I sent
  upstream.
- commit 5f62723

- dm-crypt: don't modify the data when using authenticated
  encryption (bsc#1222720, CVE-2024-26763).
- commit 3e74213

- scsi: core: Fix scsi_mode_sense() buffer length handling
  (bsc#1222662 CVE-2021-47182).
- commit 09c6ab5

- dmaengine: ti: edma: Add some null pointer checks to the edma_probe (CVE-2024-26771 bsc#1222610)
- commit 01a7e9c

- netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter
  (bsc#1222630 CVE-2024-26805).
- commit ad84c88

- Update
  patches.suse/gtp-fix-use-after-free-and-null-ptr-deref-in-gtp_gen.patch
  (bsc#1222428 CVE-2024-26793 CVE-2024-26754 bsc#1222632).
- commit b4d8fa6

- Update
  patches.suse/btrfs-fix-memory-ordering-between-normal-and-ordered-work-functions.patch
  (git-fixes CVE-2021-47189 bsc#1222706).
- commit d1ad6f0

- tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc
  (bsc#1222669 CVE-2021-47185).
- commit 24cc88e

- PCI: pciehp: Add pciehp_set_indicators() to set both indicators
  (git-fixes).
- commit deaddb6

- PCI/ASPM: Reduce severity of common clock config message
  (git-fixes).
- commit 00c0986

- PCI/ASPM: Don't warn if already in common clock mode
  (git-fixes).
- commit 231253b

- PCI/ASPM: Factor out pcie_wait_for_retrain() (git-fixes).
- PCI/ASPM: Return 0 or -ETIMEDOUT from  pcie_retrain_link()
  (git-fixes).
- PCI: Rework pcie_retrain_link() wait loop (git-fixes).
- commit 4a0cd5a

- Refresh patches.kabi/cpufeatures-kabi-fix.patch.
- commit 70aa480

- Refresh patches.suse/x86-bhi-Add-BHI-mitigation-knob.patch.
  Check for bug presence with cpu_has_bug rather than cpu_has so that
  overlapping bug/feature bits are handled correctly
- commit ec98c66

- Update
  patches.suse/scsi-lpfc-Fix-link-down-processing-to-address-NULL-p.patch
  (bsc#1192145 CVE-2021-47183 bsc#1222664).
- commit b599f2b

- Update
  patches.suse/usb-musb-tusb6010-check-return-value-after-calling-p.patch
  (git-fixes CVE-2021-47181 bsc#1222660).
- commit a0f1eaa

- tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
  (bsc#1222619).
- commit 94fc6e9

- PCI: Mark 3ware-9650SE Root Port Extended Tags as broken
  (git-fixes).
- PCI/DPC: Print all TLP Prefixes, not just the first (git-fixes).
- PCI/MSI: Prevent MSI hardware interrupt number truncation
  (git-fixes).
- PCI/sysfs: Protect driver's D3cold preference from user space
  (git-fixes).
- PCI/ASPM: Use RMW accessors for changing LNKCTL (git-fixes).
- PCI: pciehp: Use RMW accessors for changing LNKCTL (git-fixes).
- PCI: Make link retraining use RMW accessors for changing LNKCTL
  (git-fixes).
- PCI: Add locking to RMW PCI Express Capability Register
  accessors (git-fixes).
- kABI: PCI: Add locking to RMW PCI Express Capability Register
  accessors (kabi).
- PCI: qcom: Use DWC helpers for modifying the read-only DBI
  registers (git-fixes).
- PCI: qcom: Disable write access to read only registers for IP
  v2.3.3 (git-fixes).
- PCI: Add function 1 DMA alias quirk for Marvell 88SE9235
  (git-fixes).
- PCI: pciehp: Cancel bringup sequence if card is not present
  (git-fixes).
- PCI/ASPM: Avoid link retraining race (git-fixes).
- commit 5d813c6

- arp: Prevent overflow in arp_req_get() (CVE-2024-26733
  bsc#1222585).
- commit 64afd8b

- net/sched: act_mirred: don't override retval if we already
  lost the skb (CVE-2024-26733 bsc#1222585).
- commit ec837ad

- blacklist.conf: update blacklist
- commit f1ca6cb

- PCI/ASPM: Disable ASPM on MFD function removal to avoid
  use-after-free (git-fixes).
- PCI: pciehp: Fix AB-BA deadlock between reset_lock and
  device_lock (git-fixes).
- PCI: switchtec: Return -EFAULT for copy_to_user() errors
  (git-fixes).
- PCI: Avoid FLR for AMD FCH AHCI adapters (git-fixes).
- PCI/IOV: Enlarge virtfn sysfs name buffer (git-fixes).
- PCI: hotplug: Allow marking devices as disconnected during
  bind/unbind (git-fixes).
- PCI: dwc: Add unroll iATU space support to dw_pcie_disable_atu()
  (git-fixes).
- PCI: Add ACS quirk for Broadcom BCM5750x NICs (git-fixes).
- commit 60d94f2

- PCI: endpoint: Don't stop controller when unbinding endpoint
  function (git-fixes).
- PCI: qcom: Fix unbalanced PHY init on probe errors (git-fixes).
- PCI: Avoid pci_dev_lock() AB/BA deadlock with
  sriov_numvfs_store() (git-fixes).
- PCI/PM: Power up all devices during runtime resume (git-fixes).
- PCI/AER: Clear MULTI_ERR_COR/UNCOR_RCV bits (git-fixes).
- PCI: aardvark: Fix setting MSI address (git-fixes).
- PCI: aardvark: Fix support for MSI interrupts (git-fixes).
- commit fd2813d

- Refresh
  patches.suse/Bluetooth-btsdio-fix-use-after-free-bug-in-btsdio_re.patch.
  Add alternate ID for stable
- commit 38c4e25

- Bluetooth: btqcomsmd: Fix command timeout after setting BD
  address (git-fixes).
- commit de57587

- Bluetooth: hci_intel: Add check for platform_driver_register
  (git-fixes).
- commit 0e58b3a

- Bluetooth: btqca: Introduce HCI_EV_VENDOR and use it
  (git-fixes).
- commit 7e74176

- Bluetooth: btqca: Fixed a coding style error (git-fixes).
- commit 0f83a52

- blacklist.conf: false positive (introduced v5.14, not backported)
- commit e867532

- ext4: fix double-free of blocks due to wrong extents moved_len
  (bsc#1222422 CVE-2024-26704).
- commit da029ac

- Refresh
  patches.suse/bpf-sockmap-Prevent-lock-inversion-deadlock-in-map-d.patch.
- commit 6490813

- gtp: fix use-after-free and null-ptr-deref in gtp_newlink()
  (bsc#1222428 CVE-2024-26793).
- gtp: fix use-after-free and null-ptr-deref in
  gtp_genl_dump_pdp() (bsc#1222428 CVE-2024-26793).
- commit 9c6b7d6

- nfsd: Fix error cleanup path in nfsd_rename() (bsc#1221044
  CVE-2023-52591).
- commit b8b869c

- usb: musb: Modify the &amp;quot;HWVers&amp;quot; register address (git-fixes).
- commit d99cd58

- blacklist.conf: This is a feature, not a fix
- commit f6334d7

- sr9800: Add check for usbnet_get_endpoints (git-fixes).
- commit 24ceaa4

- blacklist.conf: add unneeded PCI git-fixes
- commit beed85d

- Refresh patches.kabi/cpufeatures-kabi-fix.patch.
  Fix aliasing problems if we have an extended capability which aliases a
  non-extended bug bit. The fix is to always ensure that bug bits related
  functionality doesn't use the &amp;quot;generic&amp;quot; cap functionality.
- commit c674af2

- Update
  patches.suse/KVM-s390-vsie-fix-race-during-shadow-creation.patch
  (git-fixes bsc#1220613 CVE-2023-52639 bsc#1222300).
- Update
  patches.suse/netfilter-nftables-exthdr-fix-4-byte-stack-OOB-write.patch
  (CVE-2023-4881 bsc#1215221 CVE-2023-52628 bsc#1222117).
- commit 5564fa1

- nfsd: Fix error cleanup path in nfsd_rename() (git-fixes).
- commit c8d258d

- x86/bhi: Mitigate KVM by default (bsc#1217339 CVE-2024-2201).
- commit 7079142

- x86/bhi: Add BHI mitigation knob (bsc#1217339 CVE-2024-2201).
- Update config files.
- commit 41d6371

- x86/bhi: Enumerate Branch History Injection (BHI) bug (bsc#1217339 CVE-2024-2201).
- commit 2432a6f

- x86/bhi: Define SPEC_CTRL_BHI_DIS_S (bsc#1217339 CVE-2024-2201).
- commit fe53768

- x86/bhi: Add support for clearing branch history at syscall entry (bsc#1217339 CVE-2024-2201).
- Refresh patches.kabi/cpufeatures-kabi-fix.patch.
- commit 955ab56

- Fixup NULL ptr dereference due to mistake in backporting in
  patches.suse/ext2-Avoid-reading-renamed-directory-if-parent-does-.patch.
- commit 55001e0

- Delete
  patches.suse/x86-bugs-Fix-the-SRSO-mitigation-on-Zen3-4.patch.
  the kernel fails to boot on x86:
  [    0.048461] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
  [    0.048698] MMIO Stale Data: Unknown: No mitigations
  qemu-system-x86_64: terminating on signal 15 from pid 42034 (timeout)
- commit 035c88f

- x86/cpufeature: Add missing leaf enumeration (bsc#1217339 CVE-2024-2201).
- commit 248bb60

- Update references
- commit 1bab65d

- scsi: lpfc: Fix a possible data race in
  lpfc_unregister_fcf_rescan() (bsc#1219618 CVE-2024-24855).
- commit 6004b44

- media: xc4000: Fix atomicity violation in xc4000_get_frequency
  (git-fixes bsc#1219623 CVE-2024-24861).
- commit ad0b314

- x86/bugs: Fix the SRSO mitigation on Zen3/4 (git-fixes).
- commit 8032e89

- bpf, sockmap: Prevent lock inversion deadlock in map delete elem
  (bsc#1209657 CVE-2023-0160).
- commit 40497a8

- bpf, sockmap: Fix preempt_rt splat when using raw_spin_lock_t
  (git-fixes).
- commit 3c6384f

- bnx2x: Fix enabling network interfaces without VFs (git-fixes).
- commit b60bea3

- ethernet: myri10ge: Fix missing error code in myri10ge_probe()
  (git-fixes).
- commit 71a7d56

- bnx2x: Fix missing error code in bnx2x_iov_init_one()
  (git-fixes).
- commit 813cb9c

- net: macb: ensure the device is available before accessing
  GEMGXL control registers (git-fixes).
- commit 1742349

- net/qla3xxx: fix schedule while atomic in ql_sem_spinlock
  (git-fixes).
- commit 8e475cb

- blacklist.conf: update blacklist
- commit a7a5329

- netfilter: nf_tables: disallow anonymous set with timeout flag
  (CVE-2024-26642 bsc#1221830).
- commit b3d18fd

- netfilter: ctnetlink: fix possible refcount leak in
  ctnetlink_create_conntrack() (CVE-2023-7192 bsc#1218479).
- commit 0774a95

- net: allwinner: Fix some resources leak in the error handling path of the probe and in the remove function (git-fixes).
- commit d464181

- ethernet: ucc_geth: fix definition and size of ucc_geth_tx_global_pram (git-fixes).
- commit 6895e10

- net/mlx5: Properly convey driver version to firmware (git-fixes).
- commit 09bc4c8

- net: stmmac: free tx skb buffer in stmmac_resume() (git-fixes).
- commit 7769206

- tun: honor IOCB_NOWAIT flag (git-fixes).
- commit 1f0149b

- atl1e: fix error return code in atl1e_probe() (git-fixes).
- commit da6dd80

- atl1c: fix error return code in atl1c_probe() (git-fixes).
- commit 56e0459

- net: atheros: switch from 'pci_' to 'dma_' API (git-fixes).
- commit 47ce14b

- blacklist.conf: update blacklist
- commit dc2abcd

- README.BRANCH: Remove copy of branch name
- commit 26f4895

- usb: dwc3: core: Do not perform GCTL_CORE_SOFTRESET during
  bootup (bsc#1220628 CVE-2021-46941).
- commit ebce255

- usb: dwc3: core: balance phy init and exit (bsc#1220628
  CVE-2021-46941).
- commit 8f693d2

- USB: usbfs: Don't WARN about excessively large memory
  allocations.
- commit 8172f18

- ipv6: init the accept_queue's spinlocks in inet6_create
  (bsc#1221293 CVE-2024-26614).
- commit 6bea6a5

- tcp: make sure init the accept_queue's spinlocks once
  (bsc#1221293 CVE-2024-26614).
- commit 800aa0a

- userfaultfd: release page in error path to avoid BUG_ON
  (CVE-2021-46988 bsc#1220706).
- commit bcafeec

- powerpc/mm: Fix null-pointer dereference in pgtable_cache_add
  (CVE-2023-52607 bsc#1221061).
- commit af6f33a

- Update
  patches.suse/net-nfc-llcp-Add-lock-when-modifying-device-list.patch
  (git-fixes CVE-2023-52524 bsc#1220927).
- Update
  patches.suse/net-usb-smsc75xx-Fix-uninit-value-access-in-__smsc75.patch
  (git-fixes CVE-2023-52528 bsc#1220843).
- Update
  patches.suse/nvmet-tcp-Fix-a-kernel-panic-when-host-sends-an-inva.patch
  (bsc#1217987 bsc#1217988 bsc#1217989 CVE-2023-6535 CVE-2023-6536
  CVE-2023-6356 CVE-2023-52454 bsc#1220320).
- Update
  patches.suse/ocfs2-Avoid-touching-renamed-directory-if-parent-doe.patch
  (bsc#1221044 CVE-2023-52591 CVE-2023-52590 bsc#1221088).
- Update
  patches.suse/ravb-Fix-use-after-free-issue-in-ravb_tx_timeout_wor.patch
  (bsc#1212514 CVE-2023-35827 CVE-2023-52509 bsc#1220836).
- Update
  patches.suse/x86-srso-fix-sbpb-enablement-for-spec_rstack_overflow-off.patch
  (git-fixes CVE-2023-52575 bsc#1220871).
- commit 2258ead

- Update patches.suse/mmc-moxart_remove-Fix-UAF.patch (bsc#1194516
  CVE-2022-0487 CVE-2022-48626 bsc#1220366).
- commit 10fc152

- Update
  patches.suse/0019-dm-rq-fix-double-free-of-blk_mq_tag_set-in-dev-remov.patch
  (git fixes CVE-2021-46938 bsc#1220554).
- Update
  patches.suse/ACPI-custom_method-fix-potential-use-after-free-issu.patch
  (git-fixes CVE-2021-46966 bsc#1220572).
- Update
  patches.suse/ARM-footbridge-fix-PCI-interrupt-mapping.patch
  (git-fixes CVE-2021-46909 bsc#1220442).
- Update
  patches.suse/IB-qib-Fix-memory-leak-in-qib_user_sdma_queue_pkts.patch
  (git-fixes CVE-2021-47104 bsc#1220960).
- Update
  patches.suse/NFC-nci-fix-memory-leak-in-nci_allocate_device.patch
  (git-fixes CVE-2021-47180 bsc#1221999).
- Update
  patches.suse/NFS-Don-t-corrupt-the-value-of-pg_bytes_written-in-n.patch
  (git-fixes CVE-2021-47166 bsc#1221998).
- Update
  patches.suse/NFS-Fix-an-Oopsable-condition-in-__nfs_pageio_add_re.patch
  (git-fixes CVE-2021-47167 bsc#1221991).
- Update
  patches.suse/NFS-fix-an-incorrect-limit-in-filelayout_decode_layo.patch
  (git-fixes CVE-2021-47168 bsc#1222002).
- Update
  patches.suse/NFSv4-Fix-a-NULL-pointer-dereference-in-pnfs_mark_ma.patch
  (git-fixes CVE-2021-47179 bsc#1222001).
- Update
  patches.suse/asix-fix-uninit-value-in-asix_mdio_read.patch
  (git-fixes CVE-2021-47101 bsc#1220987).
- Update
  patches.suse/bnxt_en-Fix-RX-consumer-index-logic-in-the-error-pat.patch
  (git-fixes CVE-2021-47015 bsc#1220794).
- Update
  patches.suse/btrfs-fix-race-between-transaction-aborts-and-fsyncs.patch
  (bsc#1186441 CVE-2021-46958 bsc#1220521).
- Update
  patches.suse/cifs-Return-correct-error-code-from-smb2_get_enc_key.patch
  (git-fixes CVE-2021-46960 bsc#1220528).
- Update
  patches.suse/crypto-qat-ADF_STATUS_PF_RUNNING-should-be-set-after.patch
  (git-fixes CVE-2021-47056 bsc#1220769).
- Update
  patches.suse/cxgb4-avoid-accessing-registers-when-clearing-filter.patch
  (bsc#1136345 jsc#SLE-4681 CVE-2021-47138 bsc#1221934).
- Update patches.suse/drm-amdgpu-Fix-a-use-after-free.patch
  (git-fixes CVE-2021-47142 bsc#1221952).
- Update
  patches.suse/drm-meson-fix-shutdown-crash-when-component-not-prob.patch
  (git-fixes CVE-2021-47165 bsc#1221965).
- Update
  patches.suse/ethernet-enic-Fix-a-use-after-free-bug-in-enic_hard_.patch
  (bsc#1113431 CVE-2021-46998 bsc#1220625).
- Update
  patches.suse/ext4-fix-bug-on-in-ext4_es_cache_extent-as-ext4_spli.patch
  (bsc#1187408 CVE-2021-47117 bsc#1221575).
- Update
  patches.suse/ext4-fix-memory-leak-in-ext4_fill_super.patch
  (bsc#1187409 CVE-2021-47119 bsc#1221608).
- Update
  patches.suse/gve-Add-NULL-pointer-checks-when-freeing-irqs.patch
  (bsc#1176940 CVE-2021-47141 bsc#1221949).
- Update
  patches.suse/i2c-i801-Don-t-generate-an-interrupt-on-bus-reset.patch
  (git-fixes CVE-2021-47153 bsc#1221969).
- Update patches.suse/iommu-vt-d-fix-sysfs-leak-in-alloc_iommu
  (bsc#1189272 CVE-2021-47177 bsc#1221997).
- Update
  patches.suse/ipmi-Fix-UAF-when-uninstall-ipmi_si-and-ipmi_msghand.patch
  (git-fixes CVE-2021-47100 bsc#1220985).
- Update
  patches.suse/kvm-destroy-i-o-bus-devices-on-unregister-failure-after_-sync-ing-srcu
  (CVE-2020-36312 bsc#1184509 CVE-2021-47061 bsc#1220745).
- Update
  patches.suse/kvm-stop-looking-for-coalesced-mmio-zones-if-the-bus-is-destroyed
  (CVE-2020-36312 bsc#1184509 CVE-2021-47060 bsc#1220742).
- Update
  patches.suse/md-raid1-properly-indicate-failure-when-ending-a-fai.patch
  (bsc#1185680 CVE-2021-46950 bsc#1220662).
- Update
  patches.suse/misc-uss720-fix-memory-leak-in-uss720_probe.patch
  (git-fixes CVE-2021-47173 bsc#1221993).
- Update
  patches.suse/msft-hv-2305-Drivers-hv-vmbus-Use-after-free-in-__vmbus_open.patch
  (git-fixes CVE-2021-47049 bsc#1220692).
- Update
  patches.suse/msft-hv-2316-uio_hv_generic-Fix-a-memory-leak-in-error-handling-p.patch
  (git-fixes CVE-2021-47071 bsc#1220846).
- Update
  patches.suse/msft-hv-2317-uio_hv_generic-Fix-another-memory-leak-in-error-hand.patch
  (git-fixes CVE-2021-47070 bsc#1220829).
- Update
  patches.suse/mtd-require-write-permissions-for-locking-and-badblo.patch
  (git-fixes CVE-2021-47055 bsc#1220768).
- Update
  patches.suse/nbd-Fix-NULL-pointer-in-flush_workqueue-79eb.patch
  (git-fixes CVE-2021-46981 bsc#1220611).
- Update
  patches.suse/net-fec-fix-the-potential-memory-leak-in-fec_enet_in.patch
  (git-fixes CVE-2021-47150 bsc#1221973).
- Update
  patches.suse/net-nfc-fix-use-after-free-llcp_sock_bind-connect.patch
  (CVE-2021-23134 bsc#1186060 CVE-2021-47068 bsc#1220739).
- Update
  patches.suse/net-smc-remove-device-from-smcd_dev_list-after-failed-device_add
  (git-fixes CVE-2021-47143 bsc#1221988).
- Update
  patches.suse/net-usb-fix-memory-leak-in-smsc75xx_bind.patch
  (git-fixes CVE-2021-47171 bsc#1221994).
- Update patches.suse/ocfs2-fix-data-corruption-by-fallocate.patch
  (bsc#1187412 CVE-2021-47114 bsc#1221548).
- Update
  patches.suse/pid-take-a-reference-when-initializing-cad_pid.patch
  (bsc#1114648 CVE-2021-47118 bsc#1221605).
- Update
  patches.suse/platform-x86-dell-smbios-wmi-Fix-oops-on-rmmod-dell_.patch
  (git-fixes CVE-2021-47073 bsc#1220850).
- Update
  patches.suse/powerpc-64s-Fix-crashes-when-toggling-entry-flush-ba.patch
  (bsc#1177666 git-fixes bsc#1186460 ltc#192531 CVE-2021-46990
  bsc#1220743).
- Update
  patches.suse/powerpc-64s-Fix-pte-update-for-kernel-memory-on-radi.patch
  (bsc#1055117 git-fixes CVE-2021-47034 bsc#1220687).
- Update
  patches.suse/scsi-lpfc-Fix-null-pointer-dereference-in-lpfc_prep_.patch
  (bsc#1182574 CVE-2021-47045 bsc#1220640).
- Update
  patches.suse/scsi-qla2xxx-Fix-crash-in-qla2xxx_mqueuecommand.patch
  (bsc#1185491 CVE-2021-46963 bsc#1220536).
- Update patches.suse/scsi-qla2xxx-Reserve-extra-IRQ-vectors.patch
  (bsc#1185491 CVE-2021-46964 bsc#1220538).
- Update
  patches.suse/serial-rp2-use-request_firmware-instead-of-request_f.patch
  (git-fixes CVE-2021-47169 bsc#1222000).
- Update
  patches.suse/tracing-Restructure-trace_clock_global-to-never-block.patch
  (git-fixes CVE-2021-46939 bsc#1220580).
- Update
  patches.suse/vsock-virtio-free-queued-packets-when-closing-socket.patch
  (git-fixes CVE-2021-47024 bsc#1220637).
- Update
  patches.suse/x86-kvm-Disable-kvmclock-on-all-CPUs-on-shutdown.patch
  (bsc#1185308 CVE-2021-47110 bsc#1221532).
- Update
  patches.suse/x86-kvm-Teardown-PV-features-on-boot-CPU-as-well.patch
  (bsc#1185308 CVE-2021-47112 bsc#1221541).
- commit fa763cd

- Update
  patches.suse/netlabel-fix-out-of-bounds-memory-accesses.patch
  (networking-stable-19_03_07 CVE-2019-25160 bsc#1220394).
- commit cfd1daa

- IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests (bsc#1220445 CVE-2023-52474)
- commit 71ecb14

- s390/vtime: fix average steal time calculation (git-fixes
  bsc#1221953).
- commit ccf7a1f

- s390/ptrace: handle setting of fpc register correctly
  (CVE-2023-52598 bsc#1221060 git-fixes).
- commit 0d179a3

- wifi: ath10k: fix NULL pointer dereference in
  ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() (bsc#1218336
  CVE-2023-7042).
- commit 1463c4a

- x86/CPU/AMD: Update the Zenbleed microcode revisions (git-fixes).
- commit 11a703b

- kabi fix for pNFS: Fix the pnfs block driver's calculation of
  layoutget size (git-fixes).
- commit 188e451

- pNFS: Fix the pnfs block driver's calculation of layoutget size
  (git-fixes).
- NFS: Fix O_DIRECT locking issues (git-fixes).
- NFS: Fix direct WRITE throughput regression (git-fixes).
- commit 53dafcd

- NFS: Fix an off by one in root_nfs_cat() (git-fixes).
- net: sunrpc: Fix an off by one in rpc_sockaddr2uaddr()
  (git-fixes).
- SUNRPC: fix a memleak in gss_import_v2_context (git-fixes).
- NFS: More O_DIRECT accounting fixes for error paths (git-fixes).
- NFS: Fix error handling for O_DIRECT write scheduling
  (git-fixes).
- nfs: only issue commit in DIO codepath if we have uncommitted
  data (git-fixes).
- NFS: Fix a request reference leak in
  nfs_direct_write_clear_reqs() (git-fixes).
- NFS: Fix O_DIRECT commit verifier handling (git-fixes).
- NFS: commit errors should be fatal (git-fixes).
- commit c3fe0ca

- Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security
  (bsc#1219170 CVE-2024-22099).
- commit f6c10f5

- scsi: qla2xxx: Update version to 10.02.09.200-k (bsc1221816).
- scsi: qla2xxx: Delay I/O Abort on PCI error (bsc1221816).
- scsi: qla2xxx: Change debug message during driver unload
  (bsc1221816).
- scsi: qla2xxx: Fix double free of fcport (bsc1221816).
- scsi: qla2xxx: Fix double free of the ha-&amp;gt;vp_map pointer
  (bsc1221816).
- scsi: qla2xxx: Fix command flush on cable pull (bsc1221816).
- scsi: qla2xxx: NVME|FCP prefer flag not being honored
  (bsc1221816).
- scsi: qla2xxx: Update manufacturer detail (bsc1221816).
- scsi: qla2xxx: Split FCE|EFT trace control (bsc1221816).
- scsi: qla2xxx: Fix N2N stuck connection (bsc1221816).
- scsi: qla2xxx: Prevent command send on chip reset (bsc1221816).
- commit 61951e8

- drm: bridge/panel: Cleanup connector on bridge detach (bsc#1220777, CVE-2021-47063)
  Backporting changes:
- add patch at the top of panel_bridge_detach()
- commit 760a99d

- aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts
  (bsc#1218562 CVE-2023-6270).
- commit 4e659c8

- net: Fix features skip in for_each_netdev_feature() (git-fixes).
- commit b1996ba

- rename(): avoid a deadlock in the case of parents having no
  common ancestor (bsc#1221044 CVE-2023-52591).
- commit 16f9b33

- kill lock_two_inodes() (bsc#1221044 CVE-2023-52591).
- commit c8410b2

- rename(): fix the locking of subdirectories (bsc#1221044
  CVE-2023-52591).
- commit b34d065

- f2fs: Avoid reading renamed directory if parent does not change
  (bsc#1221044 CVE-2023-52591).
- commit 95ecb76

- ext4: don't access the source subdirectory content on
  same-directory rename (bsc#1221044 CVE-2023-52591).
- commit e81c5d2

- ext2: Avoid reading renamed directory if parent does not change
  (bsc#1221044 CVE-2023-52591).
- commit 47af51c

- udf_rename(): only access the child content on cross-directory
  rename (bsc#1221044 CVE-2023-52591).
- commit 3e77e59

- ocfs2: Avoid touching renamed directory if parent does not
  change (bsc#1221044 CVE-2023-52591).
- commit ef44829

- reiserfs: Avoid touching renamed directory if parent does not
  change (git-fixes bsc#1221044 CVE-2023-52591).
  Refresh patches.suse/reiserfs-add-check-to-detect-corrupted-directory-entry.patch
  Refresh patches.suse/reiserfs-don-t-panic-on-bad-directory-entries.patch
- commit 304c6b9

- fs: don't assume arguments are non-NULL (bsc#1221044
  CVE-2023-52591).
- commit 74a158f

- fs: Restrict lock_two_nondirectories() to non-directory inodes
  (bsc#1221044 CVE-2023-52591).
- commit 2042147

- fs: ocfs2: check status values (bsc#1221044 CVE-2023-52591).
- commit 24568a1

- fs: no need to check source (bsc#1221044 CVE-2023-52591).
- commit 95711fd

- fs: Lock moved directories (bsc#1221044 CVE-2023-52591).
- commit 2b2136e

- fs: Establish locking order for unrelated directories
  (bsc#1221044 CVE-2023-52591).
- commit c49cfde

- fs: introduce lock_rename_child() helper (bsc#1221044
  CVE-2023-52591).
- commit 84b4b7d

- dwc3: switch to a global mutex (bsc#1220628 CVE-2021-46941).
- commit d93342d

- usb: dwc3: core: Do core softreset when switch mode (bsc#1220628
  CVE-2021-46941).
- blacklist.conf: needed after all for a CVE
- Refresh
  patches.suse/USB-dwc3-fix-runtime-pm-imbalance-on-probe-errors.patch.
- Refresh
  patches.suse/usb-dwc3-Fix-race-between-dwc3_set_mode-and-__dwc3_s.patch.
- commit 7ca4d31

- Input: add bounds checking to input_set_capability()
  (bsc#1218220 CVE-2022-48619).
- commit f42351b

- NFSD: Retransmit callbacks after client reconnects (git-fixes).
- NFSD: Reset cb_seq_status after NFS4ERR_DELAY (git-fixes).
- SUNRPC: fix some memleaks in gssx_dec_option_array (git-fixes).
- NFSv4.1/pnfs: Ensure we handle the error NFS4ERR_RETURNCONFLICT
  (git-fixes).
- SUNRPC: Fix RPC client cleaned up the freed pipefs dentries
  (git-fixes).
- nfsd: lock_rename() needs both directories to live on the same
  fs (git-fixes).
- pNFS/flexfiles: Check the layout validity in
  ff_layout_mirror_prepare_stats (git-fixes).
- commit 311216b

- perf/x86/lbr: Filter vsyscall addresses (bsc#1220703,
  CVE-2023-52476).
- commit ff86f16

- net/sched: Remove alias of sch_clsact (bsc#1210335 CVE-2023-1829).
- net/sched: Load modules via their alias (bsc#1210335 CVE-2023-1829).
- net/sched: Add module aliases for cls_,sch_,act_ modules
  (bsc#1210335 CVE-2023-1829).
- net/sched: Add helper macros with module names (bsc#1210335 CVE-2023-1829).
- commit 609fe5f

- x86/mmio: Disable KVM mitigation when X86_FEATURE_CLEAR_CPU_BUF is set (bsc#1213456 CVE-2023-28746).
- commit c5b2dec

- Sort patches that are already upstream
- Refresh
  patches.suse/Documentation-hw-vuln-Add-documentation-for-RFDS.patch.
- Refresh
  patches.suse/KVM-x86-Export-RFDS_NO-and-RFDS_CLEAR-to-guests.patch.
- Refresh
  patches.suse/x86-rfds-Mitigate-Register-File-Data-Sampling-RFDS.patch.
- commit 031146a

- iommu/amd: Set DTE[IntTabLen] to represent 512 IRTEs
  (git-fixes).
- commit ea9ae09

- iommu: Check if group is NULL before remove device (git-fixes).
- commit a7b6fa2

- iommu/amd: Silence warnings under memory pressure (git-fixes).
- commit cdec216

- iommu/amd: Increase interrupt remapping table limit to 512
  entries (git-fixes).
- commit c290a72

- iommu/amd: Mark interrupt as managed (git-fixes).
- commit 34b8fef

- ARM: 9064/1: hw_breakpoint: Do not directly check the event's
  overflow_handler hook (bsc#1220751 CVE-2021-47006).
- commit 605e3a7

- Refresh patches.kabi/team-Hide-new-member-header-ops.patch.
  Fix for kABI workaround.
- commit f1bcdf5

- usb: typec: class: fix typec_altmode_put_partner to put plugs
  (git-fixes).
- commit 4350c0c

- ceph: fix deadlock or deadcode of misusing dget() (bsc#1221058
  CVE-2023-52583).
- commit a413cb6

- usb: hub: Guard against accesses to uninitialized BOS
  descriptors (bsc#1220790 CVE-2023-52477).
- commit bf5af19

Package bind was updated:

- Security Fixes:  * Validating DNS messages containing a lot of DNSSEC signatures
    could cause excessive CPU load, leading to a denial-of-service
    condition. This has been fixed. (CVE-2023-50387)
    [bsc#1219823, bind-CVE-2023-50387-CVE-2023-50868.patch]
  * Preparing an NSEC3 closest encloser proof could cause excessiv
    CPU load, leading to a denial-of-service condition. This has
    been fixed. (CVE-2023-50868)
    [bsc#1219826, bind-CVE-2023-50387-CVE-2023-50868.patch]
  * Parsing DNS messages with many different names could cause
    excessive CPU load. This has been fixed. (CVE-2023-4408)
    [bsc#1219851, bind-CVE-2023-4408.patch]

Package libxml2 was updated:

- Security fix (CVE-2024-34459, bsc#1224282) buffer over-read in  xmlHTMLPrintFileContext in xmllint.c
  * Added libxml2-CVE-2024-34459.patch

Package nfs-utils was updated:

- Add 0208-mountd-add-support-for-case-insensitive-file-names.patch  Fix for bsc#1221774 - support case-insensivtive file names

Package openssl-1_1 was updated:

- Apply &amp;quot;openssl-CVE-2024-4741.patch&amp;quot; to fix a use-after-free  security vulnerability. Calling the function SSL_free_buffers()
  potentially caused memory to be accessed that was previously
  freed in some situations and a malicious attacker could attempt
  to engineer a stituation where this occurs to facilitate a
  denial-of-service attack. [CVE-2024-4741, bsc#1225551]

Package vim was updated:

- Updated to version 9.1 with patch level 0330, fixes the following problems  * Fixing bsc#1220763 - vim gets Segmentation fault after updating to version 9.1.0111-150500.20.9.1
- refreshed vim-7.3-filetype_spec.patch
- refreshed vim-7.3-filetype_ftl.patch
- Update spec.skeleton to use autosetup in place of setup macro.
- for the complete list of changes see
  https://github.com/vim/vim/compare/v9.1.0111...v9.1.0330

Package google-osconfig-agent was updated:

- Update to version 20240320.00 (bsc#1221900, bsc#1221901)  * Enable OSConfig agent to read GPG keys files with multiple entities (#537)
- from version 20240314.00
  * Update OWNERS file to replace mahmoudn GitHub
    username by personal email GitHub username (#534)
- from version 20240313.01
  * Bump google.golang.org/protobuf from 1.30.0 to 1.33.0 in /e2e_tests (#535)
- from version 20240313.00
  * Adds a console and gcloud example policies (#533)
- from version 20240228.00
  * GuestPolicies e2e: Remove ed package if exist for zypper
    startup_script in recipe-steps tests (#532)
- from version 20240126.00
  * Fix Enterprise Linux Recipe-Steps tests to install
    info dependency package in the startup-script (#530)
- from version 20240125.01
  * Fix SUSE pkg-update and pkg-no-update e2e tests (#529)
- from version 20240125.00
  * Fix zypper patch info parser to consider conflicts-pkgs float versions (#528)
- from version 20240123.01
  * Fix SUSE package update e2e tests to use another existing package (#527)
- from version 20240123.00
  * Update cis-exclude-check-once-a-day.yaml (#526)

- Update to version 20231219.00
  * Bump golang.org/x/crypto from 0.14.0 to 0.17.0 (#524)
- from version 20231207.01
  * Some change to create an agent release (#523)
- from version 20231207.00
  * Some change to create an agent release (#522)
- from version 20231205.00
  * Some change to create an agent release (#521)
- from version 20231130.02
  * Merge pull request #519 from Gulio/just-release
  * Merge branch 'master' into just-release
  * Some change to create an agent release
  * Some change to create an agent release
- from version 20231130.00
  * Some change to create an agent release (#518)
- from version 20231129.00
  * Fix parse yum updates to consider the packages under
    installing-dependencies keyword (#502)
  * Update feature names in the README file (#517)
- from version 20231128.00
  * Updating owners (#508)
- from version 20231127.00
  * Move OS policy CIS examples under the console folder (#514)
- from version 20231123.01
  * Adds three more OS Policy examples to CIS folder (#509)
  * Added ekrementeskii and MahmoudNada0 to OWNERS (#505)
- from version 20231123.00
  * docs(osconfig):add OS policy examples for CIS scanning (#503)
- from version 20231121.02
  * Added SCODE to Windows error description (#504)
- from version 20231121.01
  * Update OWNERS (#501)
  * Update go version to 1.21 (#507)
- from version 20231121.00
  * Call fqdn (#481)
- from version 20231116.00
  * Removing obsolete MS Windows 2019 images (#500)
- from version 20231107.00
  * Update owners. (#498)
- from version 20231103.02
  * Increasing test timeouts (#499)
  * Update OWNERS (#497)
- from version 20231103.01
  * Bump google.golang.org/grpc from 1.53.0 to 1.56.3 in /e2e_tests (#493)
  * Bump google.golang.org/grpc from 1.53.0 to 1.56.3 (#494)
- from version 20231103.00
  * Removing deprecated Win for containers OSs (#496)
- from version 20231027.00
  * Shortening the reported image names (#495)
- from version 20231025.00
  * Merge pull request #492 from GoogleCloudPlatform/michaljankowiak-patch-1
  * Merge branch 'master' into michaljankowiak-patch-1
  * Fixing name changes
  * Fixing rename issue
  * Fixed formatting
  * Fixed formatting
  * Fixing formatting
  * Removing support for RHEL 6, adding RHEL 9
  * Removing support for RHEL 6, adding for RHEL 9
  * Removing support for RHEL 6 and adding for RHEL 9
  * Removing step needed for RHEL 6
  * Fixing build issues
  * Removing nonexistent images and adding new ones
- from version 20231024.00
  * Removing obsolete OS images and adding new ones (#491)
- from version 20231020.00
  * Change debug messages when parsing zypper patch output (#490)
- from version 20231013.00
  * Bump golang.org/x/net from 0.7.0 to 0.17.0 (#489)
- from version 20231010.00
  * Revert &amp;quot;Added [main] section with gpgcheck to
    the agent-managed repo file (#484)&amp;quot; (#488)
- from version 20231003.00
  * Bump google.golang.org/grpc from 1.42.0 to 1.53.0 in /e2e_tests (#478)
- from version 20230920.00
  * Update OWNERS (#485)
- from version 20230912.00
  * Added [main] section with gpgcheck to the agent-managed repo file (#484)
  * Migrate empty interface to any (#483)

- Bump the golang compiler version to 1.21 (bsc#1216546)

- Update to version 20230829.00
  * Added burov, dowgird, paulinakania and Gulio to OWNERS (#482)
  &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; ./google-osconfig-agent.changes.new

Package python-base was updated:

- bsc#1221854 (CVE-2024-0450) Add  CVE-2024-0450-zipfile-avoid-quoted-overlap-zipbomb.patch
  detecting the vulnerability of the &amp;quot;quoted-overlap&amp;quot; zipbomb
  (from gh#python/cpython!110016).

- Switch to using the system libexpat (bsc#1219559,
  CVE-2023-52425)
- Make sure to remove all embedded versions of other packages
  (including expat).
- Add CVE-2023-52425-libexpat-2.6.0-remove-failing-tests.patch
  removing failing test fixing bpo#3151, which we just not
  support.
- Remove patches over those embedded packages (cffi):
  - python-2.7-libffi-aarch64.patch
  - sparc_longdouble.patch

- Modify CVE-2023-27043-email-parsing-errors.patch to fix the
  unicode string handling in email.utils.parseaddr()
  (bsc#1222537).
- Revert CVE-2022-48560-after-free-heappushpop.patch, the fix was
  unneeded.

- Switch off tests. ONLY FOR FACTORY!!! (bsc#1219306)

- Build with -std=gnu89 to build correctly with gcc14, bsc#1220970

Package google-guest-configs was updated:

- Update to version 20240307.00 (bsc#1221146, bsc#1221900, bsc#1221901)  * Support dot in NVMe device ids (#68)
- from version 20240304.00
  * google_set_hostname: Extract rsyslog service name
    with a regexp for valid systemd unit names (#67)
- from version 20240228.00
  * Remove quintonamore from OWNERS (#64)
- from version 20240119.00
  * Setup smp affinity for IRQs and XPS on A3+ VMs (#63)

- Update to version 20231214.00
  * set multiqueue: A3 check set timeout the MDS call in 1s (#62)
- from version 20231103.00
  * Update owners (#61)
  * Update owners (#58)

- Update to version 20230929.00
  * Update multinic filter to pick only pci devices (#59)

Package fdupes was updated:

- Apply &amp;quot;toctou-race-allows-arbitrary-file-deletion.patch&amp;quot; to fix a  race condition that could be exploited to delete arbitrary files.
  This patch is a back-ported and simplified version of the commit
  https://github.com/adrianlopezroche/fdupes/commit/85680897148f1ac33b55418e00334116e419717f
  introduced upstream in release 2.2.0. [bsc#1200381]

Package xfsprogs was updated:

- xfs_copy: bail out early when superblock cannot be verified  (bsc#1227150)
  - add xfs_copy-bail-out-early-when-superblock-cannot-be-ve.patch

Package openldap2 was updated:

- bsc#1217985 - Null pointer deref in referrals as part of  ldap_chain_response()
  * 0229-ITS-9262-check-referral.patch

- bsc#1220787 - increase DH param minimums to 2048 bits
  * 0228-bsc-1220787-increase-dh-param-minimums.patch

Package python36 was updated:

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

- Add CVE-2024-0397-memrace_ssl.SSLContext_cert_store.patch
  fixing bsc#1226447 (CVE-2024-0397) by removing memory race
  condition in ssl.SSLContext certificate store methods.

- Add bpo38361-syslog-no-slash-ident.patch (bsc#1222109,
  gh#python/cpython!16557) fixes syslog making default &amp;quot;ident&amp;quot;
  from sys.argv[0].
- Update CVE-2023-52425-libexpat-2.6.0-backport.patch so that
  it uses features sniffing, not just comparing version number
  (bsc#1220664, bsc#1219559, bsc#1221563, bsc#1222075).
- Remove support-expat-CVE-2022-25236-patched.patch, which was
  the previous name of this patch.
- Add CVE-2023-52425-remove-reparse_deferral-tests.patch skipping
  failing tests.
- Refresh patches:
  - CVE-2023-27043-email-parsing-errors.patch
  - fix_configure_rst.patch
  - skip_if_buildbot-extend.patch

- bsc#1221854 (CVE-2024-0450) Add
  CVE-2024-0450-zipfile-avoid-quoted-overlap-zipbomb.patch
  detecting the vulnerability of the &amp;quot;quoted-overlap&amp;quot; zipbomb
  (from gh#python/cpython!110016).
- Add bh42369-thread-safety-zipfile-SharedFile.patch (from
  gh#python/cpython!26974) required by the previous patch.
- Add expat-260-test_xml_etree-reparse-deferral.patch to make the
  interpreter work with patched libexpat in our distros.
- Move all patches from locally sourced to the branch
  opensuse-3.6 branch at GitHub repo, and move all metadata to
  commits themselves (readable in the headers of each patch).
- Add bpo-41675-modernize-siginterrupt.patch to make Python build
  cleanly even on more recent SPs of SLE-15
  (gh#python/cpython#85841).
- Remove patches:
  - bpo36263-Fix_hashlib_scrypt.patch - fix against bug in
    OpenSSL fixed in 1.1.1c (gh#openssl/openssl!8483), so this
    patch is redundant on all SUSE-supported distros
  - python-3.3.0b1-test-posix_fadvise.patch - protection
    against the kernel issues which has been fixed in
    gh#torvalds/linux@3d3727cdb07f, which has been included in
    all our kernels more recent than SLE-11.
  - python-3.3.3-skip-distutils-test_sysconfig_module.patch -
    skips a test, which should be relevant only for testing on
    Mac OS X systems with universal builds. I have no valid
    record, that this test would be ever problematic on Linux.
  - bpo-36576-skip_tests_for_OpenSSL-111.patch, which was
    included already in Python 3.5.

- (bsc#1219666, CVE-2023-6597) Add
  CVE-2023-6597-TempDir-cleaning-symlink.patch (patch from
  gh#python/cpython!99930) fixing symlink bug in cleanup of
  tempfile.TemporaryDirectory.
- Merge together bpo-36576-skip_tests_for_OpenSSL-111.patch into
  skip_SSL_tests.patch, and make them include all conditionals.

Package python3-base was updated:

- bsc#1221854 (CVE-2024-0450) Add  CVE-2024-0450-zipfile-avoid-quoted-overlap-zipbomb.patch
  detecting the vulnerability of the &amp;quot;quoted-overlap&amp;quot; zipbomb
  (from gh#python/cpython!110016).

- Add CVE-2023-52425-libexpat-2.6.0-backport.patch fixing etree
  XMLPullParser tests for Expat &amp;gt;=2.6.0 with reparse deferral
  (fixing CVE-2023-52425 or bsc#1219559).

Package wicked was updated:

- arp: increase arp-send retry value to avoid address configuration  failure due to ENOBUF reported by kernel while duplicate address
  detection with underlying bonding in 802.3ad mode reporting link
  &amp;quot;up &amp;amp; running&amp;quot; too early (bsc#1218668, gh#openSUSE/wicked#1020,
  gh#openSUSE/wicked#1022).
  [+ 0002-increase-arp-retry-attempts-on-sending-bsc1218668.patch]

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

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

Package python3 was updated:

- bsc#1221854 (CVE-2024-0450) Add  CVE-2024-0450-zipfile-avoid-quoted-overlap-zipbomb.patch
  detecting the vulnerability of the &amp;quot;quoted-overlap&amp;quot; zipbomb
  (from gh#python/cpython!110016).

- Add CVE-2023-52425-libexpat-2.6.0-backport.patch fixing etree
  XMLPullParser tests for Expat &amp;gt;=2.6.0 with reparse deferral
  (fixing CVE-2023-52425 or bsc#1219559).

Package krb5 was updated:

- Fix vulnerabilities in GSS message token handling, add patch  0016-Fix-vulnerabilities-in-GSS-message-token-handling.patch
  * CVE-2024-37370, bsc#1227186
  * CVE-2024-37371, bsc#1227187

- Fix warning executing %postun scriptlet; (bsc#1223122);

Package util-linux was updated:

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

Package python-typing was updated:

- Update to 3.10.0.0  * Implement TypeGuard (PEP 649)
  * backport ParamSpecArgs/Kwargs
  * Fixed required/optional keys with old-style TypedDict
  * Bring in protocolâs __init__ behaviour same like in python &amp;gt; 3.8
  * Support PEP 612 in typing_extensions (Python 3)
  * Also run python 3.9 in CI
  * Add OrderedDict to typing_extensions
  * Only allow installing this package for Python 2.7 and 3.4
  * Document availability of Annotated
  * Update test_typing_extensions.py
  * Apply get_args fix from bpo-40398 to typing_extensions
  * Fix tests failing with 3.10.0a2+
  * Fix stray close paren
  * Update README
  * Disable 3.5.1 build -- can't install psutils needed by pytest-xdist
  * Bump typing_extensions version to 3.7.4.3
  * Remove extra 'use' in readme
- from version 3.7.4.3
  * Revert last two changes; bump version to 3.7.4.3
- from version 3.7.4.2
  * Disallow installation on 3.5+
  * Add tox.ini for typing_extensions
  * Add PEP 613 TypeAlias to typing_extensions
  * Make tests for Annotated work with Python 3.9
  * Remove Python 3.3 from tox.ini
  * Fix flake8 failure by using Python 3.8
  * Add SupportsIndex, added in Python 3.8
  * Update package metadata
  * Bump typing_extensions version to 3.7.4.2
  * Fix ForwardRef hash and equality checks
  * Fix required and optional keys inheritance for TypedDict
  * Replace asyncio.coroutine with async-await
  * Reuse stdlib PEP 593 implementation in typing_extensions if present
  * Add .vscode and .egg-info to gitignore
  * Backport get_origin() and get_args()
  * Add clarification to package description
  * Track optional TypdeDict keys
  * Accept arbitrary keyword names in NamedTuple() and TypedDict()
  * Bump typing_extensions version
  * Add missing objects in typing_extensions/README.rst
- from version 3.7.4.1
  * Fix isinstance() with generic protocol subclasses after subscripting
  * Try fixing Travis build
    + fix tests for non-default interpreters
  * Use environment marker to specify typing dependency
  * Fix unions of protocols on Python 2
  * Bump typing_extensions version and typing dependency version
- from version 3.7.4
  * Fix subclassing builtin protocols on older Python versions
  * Move Protocol, runtime_checkable, Final, final, Literal, and TypedDict to typing
  * Add support for Python 3.8 in typing_extensions
  * Unify the implementation of annotated in src_py2 and src_py3
  * Add Annotated in python2
  * Pep 593 py3
  * Drop support of Python 3.3
  * [typing-extensions] Simple implementation for IntVar
  * Add a python 3.7+ version of Annotated to typing_extensions
  * Add SupportsIndex
  * Add TypedDict to typing_extensions
  * .travis.yml: The 'sudo' tag is now deprecated in Travis CI
  * Add Final to the README
  * Run the tests using the current Python executable
  * Fix GeneralMeta.__instancecheck__() for old style classes
  * Bump typing_extensions version
  * Add Literal[...] types to typing_extensions
  * Fix instance/subclass checks of functions against runtime protocols
  * Bump typing_extension version
  * Improve PyPI entry for typing_extensions
  * Add Final to typing_extensions
- from version 3.6.6
  * Include license file for typing-extensions and in wheels
  * Fix IO.closed to be property
  * Backport Generic.__new__ fix
  * Bump typing_extensions version before release
  * Add missing 'NoReturn' to __all__ in typing.py
  * Add annotations to NamedTuple children __new__ constructors
  * Fix typing_extensions to support PEP 560
  * Fix for issue #524
  * Pass *args and **kwargs to superclass in Generic.__new__
- Rename README.rst to README.md in %doc section

Package shadow was updated:

- bsc#916845 (CVE-2013-4235): Fix TOCTOU race condition  Add shadow-CVE-2013-4235.patch

Package wget was updated:

- Fix mishandled semicolons in the userinfo subcomponent could lead to an  insecure behavior in which data that was supposed to be in the userinfo
  subcomponent is misinterpreted to be part of the host subcomponent.
  [bsc#1226419, CVE-2024-38428, properly-re-implement-userinfo-parsing.patch]

Package glib2 was updated:

- Add patches to fix CVE-2024-34397 (boo#1224044):  glib2-CVE-2024-34397-add-ref-count-types.patch
  glib2-allocate-SignalSubscriber-structs-individually.patch
  glib2-CVE-2024-34397.patch (glgo#GNOME/glib#3268).
  glib2-fix-ibus-regression.patch (glgo#GNOME/glib#3353)

Package libzypp was updated:

- Url: Hide known password entires when writing the query part  (bsc#1050625 bsc#1177583, CVE-2017-9271)
- version 16.22.13 (0)

Package shim was updated:

- Update shim to 15.8-150300.4.20.2 from SLE15-SP3  + Version: 15.8, &amp;quot;Thu Apr 18 2024&amp;quot;
  + Update the SLE signatures
  + Include the fixes for (bsc#1215099,CVE-2023-40546),
    (bsc#1215098,CVE-2023-40547), (bsc#1215103,CVE-2023-40551),
    (bsc#1215102,CVE-2023-40550), (bsc#1215101,CVE-2023-40549),
    (bsc#1215100,CVE-2023-40548), bsc#1205588, bsc#1202120, bsc#1201066,
    (bsc#1198458, CVE-2022-28737), bsc#1198101, bsc#1193315, bsc#1193282

Package mozilla-nss was updated:

- Added nss-fips-safe-memset.patch, fixing bsc#1222811.- Removed some dead code from nss-fips-constructor-self-tests.patch.
- Rebased nss-fips-approved-crypto-non-ec.patch on above changes.
- Added nss-fips-aes-gcm-restrict.patch, fixing bsc#1222830.
- Updated nss-fips-approved-crypto-non-ec.patch, fixing bsc#1222813,
  bsc#1222814, bsc#1222821, bsc#1222822, bsc#1224118.
- Updated nss-fips-approved-crypto-non-ec.patch and
  nss-fips-constructor-self-tests.patch, fixing bsc#1222807,
  bsc#1222828, bsc#1222834.
- Updated nss-fips-approved-crypto-non-ec.patch, fixing bsc#1222804,
  bsc#1222826, bsc#1222833, bsc#1224113, bsc#1224115, bsc#1224116.

- update to NSS 3.101.1
  * bmo#1901932 - missing sqlite header.
  * bmo#1901080 - GLOBALTRUST 2020: Set Distrust After for TLS and S/MIME.
- update to NSS 3.101
  * bmo#1900413 - add diagnostic assertions for SFTKObject refcount.
  * bmo#1899759 - freeing the slot in DeleteCertAndKey if authentication failed
  * bmo#1899883 - fix formatting issues.
  * bmo#1889671 - Add Firmaprofesional CA Root-A Web to NSS.
  * bmo#1899593 - remove invalid acvp fuzz test vectors.
  * bmo#1898830 - pad short P-384 and P-521 signatures gtests.
  * bmo#1898627 - remove unused FreeBL ECC code.
  * bmo#1898830 - pad short P-384 and P-521 signatures.
  * bmo#1898825 - be less strict about ECDSA private key length.
  * bmo#1854439 - Integrate HACL* P-521.
  * bmo#1854438 - Integrate HACL* P-384.
  * bmo#1898074 - memory leak in create_objects_from_handles.
  * bmo#1898858 - ensure all input is consumed in a few places in mozilla::pkix
  * bmo#1884444 - SMIME/CMS and PKCS #12 do not integrate with modern NSS policy
  * bmo#1748105 - clean up escape handling
  * bmo#1896353 - Use lib::pkix as default validator instead of the old-one
  * bmo#1827444 - Need to add high level support for PQ signing.
  * bmo#1548723 - Certificate Compression: changing the allocation/freeing of buffer + Improving the documentation
  * bmo#1884444 - SMIME/CMS and PKCS #12 do not integrate with modern NSS policy
  * bmo#1893404 - Allow for non-full length ecdsa signature when using softoken
  * bmo#1830415 - Modification of .taskcluster.yml due to mozlint indent defects
  * bmo#1793811 - Implement support for PBMAC1 in PKCS#12
  * bmo#1897487 - disable VLA warnings for fuzz builds.
  * bmo#1895032 - remove redundant AllocItem implementation.
  * bmo#1893334 - add PK11_ReadDistrustAfterAttribute.
  * bmo#215997  - Clang-formatting of SEC_GetMgfTypeByOidTag update
  * bmo#1895012 - Set SEC_ERROR_LIBRARY_FAILURE on self-test failure
  * bmo#1894572 - sftk_getParameters(): Fix fallback to default variable after error with configfile.
  * bmo#1830415 - Switch to the mozillareleases/image_builder image
- Follow upstream changes in nss-fips-constructor-self-tests.patch (switch from ec_field_GFp to ec_field_plain)
- Remove part of nss-fips-zeroization.patch that got removed upstream
- update to NSS 3.100
  - bmo#1893029 - merge pk11_kyberSlotList into pk11_ecSlotList for
    faster Xyber operations.
  - bmo#1893752 - remove ckcapi.
  - bmo#1893162 - avoid a potential PK11GenericObject memory leak.
  - bmo#671060  - Remove incomplete ESDH code.
  - bmo#215997  - Decrypt RSA OAEP encrypted messages.
  - bmo#1887996 - Fix certutil CRLDP URI code.
  - bmo#1890069 - Don't set CKA_DERIVE for CKK_EC_EDWARDS private keys.
  - bmo#676118  - Add ability to encrypt and decrypt CMS messages using ECDH.
  - bmo#676100  - Correct Templates for key agreement in smime/cmsasn.c.
  - bmo#1548723 - Moving the decodedCert allocation to NSS.
  - bmo#1885404 - Allow developers to speed up repeated local execution
    of NSS tests that depend on certificates.
- update to NSS 3.99
  * Removing check for message len in ed25519 (bmo#1325335)
  * add ed25519 to SECU_ecName2params. (bmo#1884276)
  * add EdDSA wycheproof tests. (bmo#1325335)
  * nss/lib layer code for EDDSA. (bmo#1325335)
  * Adding EdDSA implementation. (bmo#1325335)
  * Exporting Certificate Compression types (bmo#1881027)
  * Updating ACVP docker to rust 1.74 (bmo#1880857)
  * Updating HACL* to 0f136f28935822579c244f287e1d2a1908a7e552 (bmo#1325335)
  * Add NSS_CMSRecipient_IsSupported. (bmo#1877730)
- update to NSS 3.98
  * bmo#1780432 - (CVE-2023-5388) Timing attack against RSA decryption
    in TLS
  * bmo#1879513 - Certificate Compression: enabling the check that
    the compression was advertised
  * bmo#1831552 - Move Windows workers to nss-1/b-win2022-alpha
  * bmo#1879945 - Remove Email trust bit from OISTE WISeKey
    Global Root GC CA
  * bmo#1877344 - Replace `distutils.spawn.find_executable` with
    `shutil.which` within `mach` in `nss`
  * bmo#1548723 - Certificate Compression: Updating nss_bogo_shim to
    support Certificate compression
  * bmo#1548723 - TLS Certificate Compression (RFC 8879) Implementation
  * bmo#1875356 - Add valgrind annotations to freebl kyber operations
    for constant-time execution tests
  * bmo#1870673 - Set nssckbi version number to 2.66
  * bmo#1874017 - Add Telekom Security roots
  * bmo#1873095 - Add D-Trust 2022 S/MIME roots
  * bmo#1865450 - Remove expired Security Communication RootCA1 root
  * bmo#1876179 - move keys to a slot that supports concatenation in
    PK11_ConcatSymKeys
  * bmo#1876800 - remove unmaintained tls-interop tests
  * bmo#1874937 - bogo: add support for the -ipv6 and -shim-id shim
    flags
  * bmo#1874937 - bogo: add support for the -curves shim flag and
    update Kyber expectations
  * bmo#1874937 - bogo: adjust expectation for a key usage bit test
  * bmo#1757758 - mozpkix: add option to ignore invalid subject
    alternative names
  * bmo#1841029 - Fix selfserv not stripping `publicname:` from -X value
  * bmo#1876390 - take ownership of ecckilla shims
  * bmo#1874458 - add valgrind annotations to freebl/ec.c
  * bmo#864039  - PR_INADDR_ANY needs PR_htonl before assignment to inet.ip
  * bmo#1875965 - Update zlib to 1.3.1
- Use %patch -P N instead of deprecated %patchN.
- update to NSS 3.97
  * bmo#1875506 - make Xyber768d00 opt-in by policy
  * bmo#1871631 - add libssl support for xyber768d00
  * bmo#1871630 - add PK11_ConcatSymKeys
  * bmo#1775046 - add Kyber and a PKCS#11 KEM interface to softoken
  * bmo#1871152 - add a FreeBL API for Kyber
  * bmo#1826451 - part 2: vendor github.com/pq-crystals/kyber/commit/e0d1c6ff
  * bmo#1826451 - part 1: add a script for vendoring kyber from pq-crystals repo
  * bmo#1835828 - Removing the calls to RSA Blind from loader.*
  * bmo#1874111 - fix worker type for level3 mac tasks
  * bmo#1835828 - RSA Blind implementation
  * bmo#1869642 - Remove DSA selftests
  * bmo#1873296 - read KWP testvectors from JSON
  * bmo#1822450 - Backed out changeset dcb174139e4f
  * bmo#1822450 - Fix CKM_PBE_SHA1_DES2_EDE_CBC derivation
  * bmo#1871219 - Wrap CC shell commands in gyp expansions
- update to NSS 3.96.1
  * bmo#1869408 - Use pypi dependencies for MacOS worker in ./build_gyp.sh
  * bmo#1830978 - p7sign: add -a hash and -u certusage (also p7verify cleanups)
  * bmo#1867408 - add a defensive check for large ssl_DefSend return values
  * bmo#1869378 - Add dependency to the taskcluster script for Darwin
  * bmo#1869378 - Upgrade version of the MacOS worker for the CI
- add nss-allow-slow-tests-s390x.patch: &amp;quot;certutil dump keys with
  explicit default trust flags&amp;quot; test needs longer than the allowed
  6 seconds on s390x
- update to NSS 3.95
  * bmo#1842932 - Bump builtins version number.
  * bmo#1851044 - Remove Email trust bit from Autoridad de Certificacion
    Firmaprofesional CIF A62634068 root cert.
  * bmo#1855318 - Remove 4 DigiCert (Symantec/Verisign) Root Certificates
  * bmo#1851049 - Remove 3 TrustCor Root Certificates from NSS.
  * bmo#1850982 - Remove Camerfirma root certificates from NSS.
  * bmo#1842935 - Remove old Autoridad de Certificacion Firmaprofesional
    Certificate.
  * bmo#1860670 - Add four Commscope root certificates to NSS.
  * bmo#1850598 - Add TrustAsia Global Root CA G3 and G4 root certificates.
  * bmo#1863605 - Include P-384 and P-521 Scalar Validation from HACL*
  * bmo#1861728 - Include P-256 Scalar Validation from HACL*.
  * bmo#1861265 - After the HACL 256 ECC patch, NSS incorrectly encodes
    256 ECC without DER wrapping at the softoken level
  * bmo#1837987 - Add means to provide library parameters to C_Initialize
  * bmo#1573097 - clang format
  * bmo#1854795 - add OSXSAVE and XCR0 tests to AVX2 detection.
  * bmo#1858241 - Typo in ssl3_AppendHandshakeNumber
  * bmo#1858241 - Introducing input check of ssl3_AppendHandshakeNumber
  * bmo#1573097 - Fix Invalid casts in instance.c
- update to NSS 3.94
  * bmo#1853737 - Updated code and commit ID for HACL*
  * bmo#1840510 - update ACVP fuzzed test vector: refuzzed with
    current NSS
  * bmo#1827303 - Softoken C_ calls should use system FIPS setting
    to select NSC_ or FC_ variants
  * bmo#1774659 - NSS needs a database tool that can dump the low level
    representation of the database
  * bmo#1852179 - declare string literals using char in pkixnames_tests.cpp
  * bmo#1852179 - avoid implicit conversion for ByteString
  * bmo#1818766 - update rust version for acvp docker
  * bmo#1852011 - Moving the init function of the mpi_ints before
    clean-up in ec.c
  * bmo#1615555 - P-256 ECDH and ECDSA from HACL*
  * bmo#1840510 - Add ACVP test vectors to the repository
  * bmo#1849077 - Stop relying on std::basic_string&amp;lt;uint8_t&amp;gt;
  * bmo#1847845 - Transpose the PPC_ABI check from Makefile to gyp
- rebased patches
- added nss-fips-test.patch to fix broken test
- Update to NSS 3.93:
  * bmo#1849471 - Update zlib in NSS to 1.3.
  * bmo#1848183 - softoken: iterate hashUpdate calls for long inputs.
  * bmo#1813401 - regenerate NameConstraints test certificates (boo#1214980).
- Rebase nss-fips-pct-pubkeys.patch.
- update to NSS 3.92
  * bmo#1822935 - Set nssckbi version number to 2.62
  * bmo#1833270 - Add 4 Atos TrustedRoot Root CA certificates to NSS
  * bmo#1839992 - Add 4 SSL.com Root CA certificates
  * bmo#1840429 - Add Sectigo E46 and R46 Root CA certificates
  * bmo#1840437 - Add LAWtrust Root CA2 (4096)
  * bmo#1822936 - Remove E-Tugra Certification Authority root
  * bmo#1827224 - Remove Camerfirma Chambers of Commerce Root.
  * bmo#1840505 - Remove Hongkong Post Root CA 1
  * bmo#1842928 - Remove E-Tugra Global Root CA ECC v3 and RSA v3
  * bmo#1842937 - Avoid redefining BYTE_ORDER on hppa Linux
- update to NSS 3.91
  * bmo#1837431 - Implementation of the HW support check for ADX instruction
  * bmo#1836925 - Removing the support of Curve25519
  * bmo#1839795 - Fix comment about the addition of ticketSupportsEarlyData
  * bmo#1839327 - Adding args to enable-legacy-db build
  * bmo#1835357 - dbtests.sh failure in &amp;quot;certutil dump keys with explicit
    default trust flags&amp;quot;
  * bmo#1837617 - Initialize flags in slot structures
  * bmo#1835425 - Improve the length check of RSA input to avoid heap overflow
  * bmo#1829112 - Followup Fixes
  * bmo#1784253 - avoid processing unexpected inputs by checking for
    m_exptmod base sign
  * bmo#1826652 - add a limit check on order_k to avoid infinite loop
  * bmo#1834851 - Update HACL* to commit 5f6051d2
  * bmo#1753026 - add SHA3 to cryptohi and softoken
  * bmo#1753026 - HACL SHA3
  * bmo#1836781 - Disabling ASM C25519 for A but X86_64
- removed upstreamed patch nss-fix-bmo1836925.patch

- update to NSS 3.90.3
  * bmo#1901080 - GLOBALTRUST 2020: Set Distrust After for TLS and S/MIME.
  * bmo#1748105 - clean up escape handling.
  * bmo#1895032 - remove redundant AllocItem implementation.
  * bmo#1836925 - Disable ASM support for Curve25519.
  * bmo#1836781 - Disable ASM support for Curve25519 for all but X86_64.
- remove upstreamed nss-fix-bmo1836925.patch

- Adding nss-fips-bsc1223724.patch to fix startup crash of Firefox
  when using FIPS-mode (bsc#1223724).

- Added &amp;quot;Provides: nss&amp;quot; so other RPMs that require 'nss' can
  be installed (jira PED-6358).

Package less was updated:

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

Package release-notes-sles was updated:

- 12.5.20240614 (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)

Package cups was updated:

- cups-1.7.5-CVE-2024-35235.patch for CUPS 1.7.5 in SLE12  is derived from our cups-2.2.7-CVE-2024-35235.patch for SLE15
  which was derived from the upstream patch for CUPS 2.5
  to behave backward compatible for CUPS 1.7.5 in SLE12
  to fix CVE-2024-35235
  &amp;quot;cupsd Listen port arbitrary chmod 0140777&amp;quot;
  without the more secure but backward-incompatible behaviour
  of the upstream patch for CUPS 2.5
  that ignores domain sockets specified in 'Listen' entries
  in /etc/cups/cupsd.conf when cupsd is lauched via systemd
  (in particular when launched on-demand by systemd)
  https://github.com/OpenPrinting/cups/security/advisories/GHSA-vvwp-mv6j-hw6f
  bsc#1225365

Package python was updated:

- bsc#1221854 (CVE-2024-0450) Add  CVE-2024-0450-zipfile-avoid-quoted-overlap-zipbomb.patch
  detecting the vulnerability of the &amp;quot;quoted-overlap&amp;quot; zipbomb
  (from gh#python/cpython!110016).

- Switch to using the system libexpat (bsc#1219559,
  CVE-2023-52425)
- Make sure to remove all embedded versions of other packages
  (including expat).
- Add CVE-2023-52425-libexpat-2.6.0-remove-failing-tests.patch
  removing failing test fixing bpo#3151, which we just not
  support.
- Remove patches over those embedded packages (cffi):
  - python-2.7-libffi-aarch64.patch
  - sparc_longdouble.patch

- Modify CVE-2023-27043-email-parsing-errors.patch to fix the
  unicode string handling in email.utils.parseaddr()
  (bsc#1222537).
- Revert CVE-2022-48560-after-free-heappushpop.patch, the fix was
  unneeded.

- Switch off tests. ONLY FOR FACTORY!!! (bsc#1219306)

- Build with -std=gnu89 to build correctly with gcc14, bsc#1220970

Package glibc was updated:

- nscd-Fix-use-after-free-in-addgetnetgrentX.patch: nscd: Fix  use-after-free in addgetnetgrentX (BZ #23520)
- glibc-CVE-2024-33599-nscd-Stack-based-buffer-overflow-in-n.patch:
  nscd: Stack-based buffer overflow in netgroup cache
  (CVE-2024-33599, bsc#1223423, BZ #31677)
- glibc-CVE-2024-33600-nscd-Avoid-null-pointer-crashes-after.patch:
  nscd: Avoid null pointer crashes after notfound response
  (CVE-2024-33600, bsc#1223424, BZ #31678)
- glibc-CVE-2024-33600-nscd-Do-not-send-missing-not-found-re.patch:
  nscd: Do not send missing not-found response in addgetnetgrentX
  (CVE-2024-33600, bsc#1223424, BZ #31678)
- glibc-CVE-2024-33601-CVE-2024-33602-nscd-netgroup-Use-two.patch:
  netgroup: Use two buffers in addgetnetgrentX (CVE-2024-33601,
  CVE-2024-33602, bsc#1223425, BZ #31680)
- nscd-netgroup-cache-timeout.patch: Use time_t for return type of
  addgetnetgrentX (CVE-2024-33602, bsc#1223425)

- elf-ifunc-subtests-nonpie.patch: elf: Disable some subtests of
  ifuncmain1, ifuncmain5 for !PIE
- iconv-iso-2022-cn-ext.patch: iconv: ISO-2022-CN-EXT: fix out-of-bound
  writes when writing escape sequence (CVE-2024-2961, bsc#1222992)

Package suseconnect-ng was updated:

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

Package python-requests was updated:

- Add CVE-2024-35195.patch (CVE-2024-35195, bsc#1224788)- Add httpbin.patch to fix a test failure caused by the previous patch.

Package google-guest-oslogin was updated:

- Fix file permissions for google_authorized_principals binary (bsc#1222171)
- Update to version 20240311.00 (bsc#1218548, bsc#1221900, bsc#1221901)
  * pam: Bring back pam's account management implementation (#133)
  * Change error messages when checking login policy (#129)
  * Remove quintonamore from OWNERS (#128)

Package avahi was updated:

- Add avahi-CVE-2023-38472.patch: Fix reachable assertion in  avahi_rdata_parse (bsc#1216853, CVE-2023-38472).

- Add avahi-CVE-2023-38470.patch: Ensure each label is at least one
  byte long (bsc#1215947, CVE-2023-38470).

Package zypper was updated:

- Show rpm install size before installing (bsc#1224771)  If filesystem snapshots are taken before the installation (e.g.
  by snapper) no disk space is freed by removing old packages. In
  this case the install size of all packages is a hint how much
  additional disk space is needed by the new packages static
  content.
- version 1.13.67

- clean: Do not report an error if no repos are defined at all
  (bsc#1223971)
- version 1.13.66

</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-byos-v20240727-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-byos-v20240727-x86-64">
      <Branch Type="Product Name" Name="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
        <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
      </Branch>
    </Branch>
    <Branch Type="Product Version" Name="bind-utils-9.11.22-3.52.1">
      <FullProductName ProductID="bind-utils-9.11.22-3.52.1">bind-utils-9.11.22-3.52.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cups-libs-1.7.5-20.49.1">
      <FullProductName ProductID="cups-libs-1.7.5-20.49.1">cups-libs-1.7.5-20.49.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="fdupes-1.61-8.3.1">
      <FullProductName ProductID="fdupes-1.61-8.3.1">fdupes-1.61-8.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glib2-tools-2.48.2-12.37.1">
      <FullProductName ProductID="glib2-tools-2.48.2-12.37.1">glib2-tools-2.48.2-12.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-2.22-114.34.1">
      <FullProductName ProductID="glibc-2.22-114.34.1">glibc-2.22-114.34.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-i18ndata-2.22-114.34.1">
      <FullProductName ProductID="glibc-i18ndata-2.22-114.34.1">glibc-i18ndata-2.22-114.34.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-locale-2.22-114.34.1">
      <FullProductName ProductID="glibc-locale-2.22-114.34.1">glibc-locale-2.22-114.34.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-agent-20240314.00-1.38.2">
      <FullProductName ProductID="google-guest-agent-20240314.00-1.38.2">google-guest-agent-20240314.00-1.38.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-configs-20240307.00-1.29.1">
      <FullProductName ProductID="google-guest-configs-20240307.00-1.29.1">google-guest-configs-20240307.00-1.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-oslogin-20240311.00-1.34.1">
      <FullProductName ProductID="google-guest-oslogin-20240311.00-1.34.1">google-guest-oslogin-20240311.00-1.34.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-osconfig-agent-20240320.00-1.26.3">
      <FullProductName ProductID="google-osconfig-agent-20240320.00-1.26.3">google-osconfig-agent-20240320.00-1.26.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kernel-default-4.12.14-122.222.1">
      <FullProductName ProductID="kernel-default-4.12.14-122.222.1">kernel-default-4.12.14-122.222.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="krb5-1.16.3-46.15.1">
      <FullProductName ProductID="krb5-1.16.3-46.15.1">krb5-1.16.3-46.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="krb5-client-1.16.3-46.15.1">
      <FullProductName ProductID="krb5-client-1.16.3-46.15.1">krb5-client-1.16.3-46.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="less-458-7.15.1">
      <FullProductName ProductID="less-458-7.15.1">less-458-7.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libavahi-client3-0.6.32-32.27.1">
      <FullProductName ProductID="libavahi-client3-0.6.32-32.27.1">libavahi-client3-0.6.32-32.27.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libavahi-common3-0.6.32-32.27.1">
      <FullProductName ProductID="libavahi-common3-0.6.32-32.27.1">libavahi-common3-0.6.32-32.27.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libbind9-161-9.11.22-3.52.1">
      <FullProductName ProductID="libbind9-161-9.11.22-3.52.1">libbind9-161-9.11.22-3.52.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libblkid1-2.33.2-4.39.14">
      <FullProductName ProductID="libblkid1-2.33.2-4.39.14">libblkid1-2.33.2-4.39.14</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libdns1110-9.11.22-3.52.1">
      <FullProductName ProductID="libdns1110-9.11.22-3.52.1">libdns1110-9.11.22-3.52.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libfastjson4-0.99.8-3.6.1">
      <FullProductName ProductID="libfastjson4-0.99.8-3.6.1">libfastjson4-0.99.8-3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libfdisk1-2.33.2-4.39.14">
      <FullProductName ProductID="libfdisk1-2.33.2-4.39.14">libfdisk1-2.33.2-4.39.14</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgcc_s1-13.3.0+git8781-1.13.1">
      <FullProductName ProductID="libgcc_s1-13.3.0+git8781-1.13.1">libgcc_s1-13.3.0+git8781-1.13.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgio-2_0-0-2.48.2-12.37.1">
      <FullProductName ProductID="libgio-2_0-0-2.48.2-12.37.1">libgio-2_0-0-2.48.2-12.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libglib-2_0-0-2.48.2-12.37.1">
      <FullProductName ProductID="libglib-2_0-0-2.48.2-12.37.1">libglib-2_0-0-2.48.2-12.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgmodule-2_0-0-2.48.2-12.37.1">
      <FullProductName ProductID="libgmodule-2_0-0-2.48.2-12.37.1">libgmodule-2_0-0-2.48.2-12.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgobject-2_0-0-2.48.2-12.37.1">
      <FullProductName ProductID="libgobject-2_0-0-2.48.2-12.37.1">libgobject-2_0-0-2.48.2-12.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libirs161-9.11.22-3.52.1">
      <FullProductName ProductID="libirs161-9.11.22-3.52.1">libirs161-9.11.22-3.52.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libisc1107-9.11.22-3.52.1">
      <FullProductName ProductID="libisc1107-9.11.22-3.52.1">libisc1107-9.11.22-3.52.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libisccc161-9.11.22-3.52.1">
      <FullProductName ProductID="libisccc161-9.11.22-3.52.1">libisccc161-9.11.22-3.52.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libisccfg163-9.11.22-3.52.1">
      <FullProductName ProductID="libisccfg163-9.11.22-3.52.1">libisccfg163-9.11.22-3.52.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libldap-2_4-2-2.4.41-22.24.2">
      <FullProductName ProductID="libldap-2_4-2-2.4.41-22.24.2">libldap-2_4-2-2.4.41-22.24.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="liblwres161-9.11.22-3.52.1">
      <FullProductName ProductID="liblwres161-9.11.22-3.52.1">liblwres161-9.11.22-3.52.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libmount1-2.33.2-4.39.14">
      <FullProductName ProductID="libmount1-2.33.2-4.39.14">libmount1-2.33.2-4.39.14</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libopenssl1_1-1.1.1d-2.107.1">
      <FullProductName ProductID="libopenssl1_1-1.1.1d-2.107.1">libopenssl1_1-1.1.1d-2.107.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython2_7-1_0-2.7.18-33.35.1">
      <FullProductName ProductID="libpython2_7-1_0-2.7.18-33.35.1">libpython2_7-1_0-2.7.18-33.35.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython3_4m1_0-3.4.10-25.130.1">
      <FullProductName ProductID="libpython3_4m1_0-3.4.10-25.130.1">libpython3_4m1_0-3.4.10-25.130.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython3_6m1_0-3.6.15-58.1">
      <FullProductName ProductID="libpython3_6m1_0-3.6.15-58.1">libpython3_6m1_0-3.6.15-58.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsmartcols1-2.33.2-4.39.14">
      <FullProductName ProductID="libsmartcols1-2.33.2-4.39.14">libsmartcols1-2.33.2-4.39.14</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libstdc++6-13.3.0+git8781-1.13.1">
      <FullProductName ProductID="libstdc++6-13.3.0+git8781-1.13.1">libstdc++6-13.3.0+git8781-1.13.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsuseconnect-1.9.0-3.15.4">
      <FullProductName ProductID="libsuseconnect-1.9.0-3.15.4">libsuseconnect-1.9.0-3.15.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libuuid1-2.33.2-4.39.14">
      <FullProductName ProductID="libuuid1-2.33.2-4.39.14">libuuid1-2.33.2-4.39.14</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxml2-2-2.9.4-46.75.1">
      <FullProductName ProductID="libxml2-2-2.9.4-46.75.1">libxml2-2-2.9.4-46.75.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libzmq3-4.0.4-15.8.1">
      <FullProductName ProductID="libzmq3-4.0.4-15.8.1">libzmq3-4.0.4-15.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libzypp-16.22.13-65.3">
      <FullProductName ProductID="libzypp-16.22.13-65.3">libzypp-16.22.13-65.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nss-certs-3.101.1-58.118.1">
      <FullProductName ProductID="mozilla-nss-certs-3.101.1-58.118.1">mozilla-nss-certs-3.101.1-58.118.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nfs-client-1.3.0-34.53.5">
      <FullProductName ProductID="nfs-client-1.3.0-34.53.5">nfs-client-1.3.0-34.53.5</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nfs-kernel-server-1.3.0-34.53.5">
      <FullProductName ProductID="nfs-kernel-server-1.3.0-34.53.5">nfs-kernel-server-1.3.0-34.53.5</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nscd-2.22-114.34.1">
      <FullProductName ProductID="nscd-2.22-114.34.1">nscd-2.22-114.34.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openldap2-client-2.4.41-22.24.2">
      <FullProductName ProductID="openldap2-client-2.4.41-22.24.2">openldap2-client-2.4.41-22.24.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python-2.7.18-33.35.1">
      <FullProductName ProductID="python-2.7.18-33.35.1">python-2.7.18-33.35.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python-base-2.7.18-33.35.1">
      <FullProductName ProductID="python-base-2.7.18-33.35.1">python-base-2.7.18-33.35.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python-bind-9.11.22-3.52.1">
      <FullProductName ProductID="python-bind-9.11.22-3.52.1">python-bind-9.11.22-3.52.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python-pyOpenSSL-17.1.0-4.26.1">
      <FullProductName ProductID="python-pyOpenSSL-17.1.0-4.26.1">python-pyOpenSSL-17.1.0-4.26.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python-requests-2.24.0-8.17.1">
      <FullProductName ProductID="python-requests-2.24.0-8.17.1">python-requests-2.24.0-8.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python-xml-2.7.18-33.35.1">
      <FullProductName ProductID="python-xml-2.7.18-33.35.1">python-xml-2.7.18-33.35.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-3.4.10-25.130.1">
      <FullProductName ProductID="python3-3.4.10-25.130.1">python3-3.4.10-25.130.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-base-3.4.10-25.130.1">
      <FullProductName ProductID="python3-base-3.4.10-25.130.1">python3-base-3.4.10-25.130.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-pyOpenSSL-17.1.0-4.26.1">
      <FullProductName ProductID="python3-pyOpenSSL-17.1.0-4.26.1">python3-pyOpenSSL-17.1.0-4.26.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-typing-3.10.0.0-3.3.1">
      <FullProductName ProductID="python3-typing-3.10.0.0-3.3.1">python3-typing-3.10.0.0-3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python36-base-3.6.15-58.1">
      <FullProductName ProductID="python36-base-3.6.15-58.1">python36-base-3.6.15-58.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="regionServiceClientConfigGCE-4.1.0-5.15.1">
      <FullProductName ProductID="regionServiceClientConfigGCE-4.1.0-5.15.1">regionServiceClientConfigGCE-4.1.0-5.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="release-notes-sles-12.5.20240614-3.37.2">
      <FullProductName ProductID="release-notes-sles-12.5.20240614-3.37.2">release-notes-sles-12.5.20240614-3.37.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="shadow-4.2.1-36.12.1">
      <FullProductName ProductID="shadow-4.2.1-36.12.1">shadow-4.2.1-36.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="shim-15.8-25.30.1">
      <FullProductName ProductID="shim-15.8-25.30.1">shim-15.8-25.30.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suseconnect-ng-1.9.0-3.15.4">
      <FullProductName ProductID="suseconnect-ng-1.9.0-3.15.4">suseconnect-ng-1.9.0-3.15.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suseconnect-ruby-bindings-1.9.0-3.15.4">
      <FullProductName ProductID="suseconnect-ruby-bindings-1.9.0-3.15.4">suseconnect-ruby-bindings-1.9.0-3.15.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="util-linux-2.33.2-4.39.14">
      <FullProductName ProductID="util-linux-2.33.2-4.39.14">util-linux-2.33.2-4.39.14</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="util-linux-systemd-2.33.2-4.39.12">
      <FullProductName ProductID="util-linux-systemd-2.33.2-4.39.12">util-linux-systemd-2.33.2-4.39.12</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-9.1.0330-17.33.1">
      <FullProductName ProductID="vim-9.1.0330-17.33.1">vim-9.1.0330-17.33.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-data-common-9.1.0330-17.33.1">
      <FullProductName ProductID="vim-data-common-9.1.0330-17.33.1">vim-data-common-9.1.0330-17.33.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wget-1.14-21.19.1">
      <FullProductName ProductID="wget-1.14-21.19.1">wget-1.14-21.19.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wicked-0.6.75-3.43.1">
      <FullProductName ProductID="wicked-0.6.75-3.43.1">wicked-0.6.75-3.43.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wicked-service-0.6.75-3.43.1">
      <FullProductName ProductID="wicked-service-0.6.75-3.43.1">wicked-service-0.6.75-3.43.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="xfsprogs-4.15.0-3.21.2">
      <FullProductName ProductID="xfsprogs-4.15.0-3.21.2">xfsprogs-4.15.0-3.21.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="zypper-1.13.67-21.64.1">
      <FullProductName ProductID="zypper-1.13.67-21.64.1">zypper-1.13.67-21.64.1</FullProductName>
    </Branch>
    <Relationship ProductReference="bind-utils-9.11.22-3.52.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:bind-utils-9.11.22-3.52.1">bind-utils-9.11.22-3.52.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cups-libs-1.7.5-20.49.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:cups-libs-1.7.5-20.49.1">cups-libs-1.7.5-20.49.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="fdupes-1.61-8.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:fdupes-1.61-8.3.1">fdupes-1.61-8.3.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glib2-tools-2.48.2-12.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glib2-tools-2.48.2-12.37.1">glib2-tools-2.48.2-12.37.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-2.22-114.34.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-2.22-114.34.1">glibc-2.22-114.34.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-i18ndata-2.22-114.34.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-i18ndata-2.22-114.34.1">glibc-i18ndata-2.22-114.34.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-locale-2.22-114.34.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-locale-2.22-114.34.1">glibc-locale-2.22-114.34.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-agent-20240314.00-1.38.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:google-guest-agent-20240314.00-1.38.2">google-guest-agent-20240314.00-1.38.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-configs-20240307.00-1.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:google-guest-configs-20240307.00-1.29.1">google-guest-configs-20240307.00-1.29.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-oslogin-20240311.00-1.34.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:google-guest-oslogin-20240311.00-1.34.1">google-guest-oslogin-20240311.00-1.34.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-osconfig-agent-20240320.00-1.26.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:google-osconfig-agent-20240320.00-1.26.3">google-osconfig-agent-20240320.00-1.26.3 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kernel-default-4.12.14-122.222.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1">kernel-default-4.12.14-122.222.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="krb5-1.16.3-46.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:krb5-1.16.3-46.15.1">krb5-1.16.3-46.15.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="krb5-client-1.16.3-46.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:krb5-client-1.16.3-46.15.1">krb5-client-1.16.3-46.15.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="less-458-7.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:less-458-7.15.1">less-458-7.15.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libavahi-client3-0.6.32-32.27.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libavahi-client3-0.6.32-32.27.1">libavahi-client3-0.6.32-32.27.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libavahi-common3-0.6.32-32.27.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libavahi-common3-0.6.32-32.27.1">libavahi-common3-0.6.32-32.27.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libbind9-161-9.11.22-3.52.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libbind9-161-9.11.22-3.52.1">libbind9-161-9.11.22-3.52.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libblkid1-2.33.2-4.39.14" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libblkid1-2.33.2-4.39.14">libblkid1-2.33.2-4.39.14 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libdns1110-9.11.22-3.52.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libdns1110-9.11.22-3.52.1">libdns1110-9.11.22-3.52.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfastjson4-0.99.8-3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libfastjson4-0.99.8-3.6.1">libfastjson4-0.99.8-3.6.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfdisk1-2.33.2-4.39.14" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libfdisk1-2.33.2-4.39.14">libfdisk1-2.33.2-4.39.14 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgcc_s1-13.3.0+git8781-1.13.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libgcc_s1-13.3.0+git8781-1.13.1">libgcc_s1-13.3.0+git8781-1.13.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgio-2_0-0-2.48.2-12.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libgio-2_0-0-2.48.2-12.37.1">libgio-2_0-0-2.48.2-12.37.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libglib-2_0-0-2.48.2-12.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libglib-2_0-0-2.48.2-12.37.1">libglib-2_0-0-2.48.2-12.37.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgmodule-2_0-0-2.48.2-12.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libgmodule-2_0-0-2.48.2-12.37.1">libgmodule-2_0-0-2.48.2-12.37.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgobject-2_0-0-2.48.2-12.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libgobject-2_0-0-2.48.2-12.37.1">libgobject-2_0-0-2.48.2-12.37.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libirs161-9.11.22-3.52.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libirs161-9.11.22-3.52.1">libirs161-9.11.22-3.52.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libisc1107-9.11.22-3.52.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libisc1107-9.11.22-3.52.1">libisc1107-9.11.22-3.52.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libisccc161-9.11.22-3.52.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libisccc161-9.11.22-3.52.1">libisccc161-9.11.22-3.52.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libisccfg163-9.11.22-3.52.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libisccfg163-9.11.22-3.52.1">libisccfg163-9.11.22-3.52.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libldap-2_4-2-2.4.41-22.24.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libldap-2_4-2-2.4.41-22.24.2">libldap-2_4-2-2.4.41-22.24.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="liblwres161-9.11.22-3.52.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:liblwres161-9.11.22-3.52.1">liblwres161-9.11.22-3.52.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libmount1-2.33.2-4.39.14" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libmount1-2.33.2-4.39.14">libmount1-2.33.2-4.39.14 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libopenssl1_1-1.1.1d-2.107.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libopenssl1_1-1.1.1d-2.107.1">libopenssl1_1-1.1.1d-2.107.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython2_7-1_0-2.7.18-33.35.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libpython2_7-1_0-2.7.18-33.35.1">libpython2_7-1_0-2.7.18-33.35.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython3_4m1_0-3.4.10-25.130.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libpython3_4m1_0-3.4.10-25.130.1">libpython3_4m1_0-3.4.10-25.130.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython3_6m1_0-3.6.15-58.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libpython3_6m1_0-3.6.15-58.1">libpython3_6m1_0-3.6.15-58.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsmartcols1-2.33.2-4.39.14" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libsmartcols1-2.33.2-4.39.14">libsmartcols1-2.33.2-4.39.14 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libstdc++6-13.3.0+git8781-1.13.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libstdc++6-13.3.0+git8781-1.13.1">libstdc++6-13.3.0+git8781-1.13.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsuseconnect-1.9.0-3.15.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libsuseconnect-1.9.0-3.15.4">libsuseconnect-1.9.0-3.15.4 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libuuid1-2.33.2-4.39.14" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libuuid1-2.33.2-4.39.14">libuuid1-2.33.2-4.39.14 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxml2-2-2.9.4-46.75.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libxml2-2-2.9.4-46.75.1">libxml2-2-2.9.4-46.75.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libzmq3-4.0.4-15.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libzmq3-4.0.4-15.8.1">libzmq3-4.0.4-15.8.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libzypp-16.22.13-65.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libzypp-16.22.13-65.3">libzypp-16.22.13-65.3 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nss-certs-3.101.1-58.118.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:mozilla-nss-certs-3.101.1-58.118.1">mozilla-nss-certs-3.101.1-58.118.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nfs-client-1.3.0-34.53.5" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:nfs-client-1.3.0-34.53.5">nfs-client-1.3.0-34.53.5 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nfs-kernel-server-1.3.0-34.53.5" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:nfs-kernel-server-1.3.0-34.53.5">nfs-kernel-server-1.3.0-34.53.5 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nscd-2.22-114.34.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:nscd-2.22-114.34.1">nscd-2.22-114.34.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openldap2-client-2.4.41-22.24.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:openldap2-client-2.4.41-22.24.2">openldap2-client-2.4.41-22.24.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python-2.7.18-33.35.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-2.7.18-33.35.1">python-2.7.18-33.35.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python-base-2.7.18-33.35.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-base-2.7.18-33.35.1">python-base-2.7.18-33.35.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python-bind-9.11.22-3.52.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-bind-9.11.22-3.52.1">python-bind-9.11.22-3.52.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python-pyOpenSSL-17.1.0-4.26.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-pyOpenSSL-17.1.0-4.26.1">python-pyOpenSSL-17.1.0-4.26.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python-requests-2.24.0-8.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-requests-2.24.0-8.17.1">python-requests-2.24.0-8.17.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python-xml-2.7.18-33.35.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-xml-2.7.18-33.35.1">python-xml-2.7.18-33.35.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-3.4.10-25.130.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python3-3.4.10-25.130.1">python3-3.4.10-25.130.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-base-3.4.10-25.130.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python3-base-3.4.10-25.130.1">python3-base-3.4.10-25.130.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-pyOpenSSL-17.1.0-4.26.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python3-pyOpenSSL-17.1.0-4.26.1">python3-pyOpenSSL-17.1.0-4.26.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-typing-3.10.0.0-3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python3-typing-3.10.0.0-3.3.1">python3-typing-3.10.0.0-3.3.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python36-base-3.6.15-58.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python36-base-3.6.15-58.1">python36-base-3.6.15-58.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="regionServiceClientConfigGCE-4.1.0-5.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:regionServiceClientConfigGCE-4.1.0-5.15.1">regionServiceClientConfigGCE-4.1.0-5.15.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="release-notes-sles-12.5.20240614-3.37.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:release-notes-sles-12.5.20240614-3.37.2">release-notes-sles-12.5.20240614-3.37.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="shadow-4.2.1-36.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:shadow-4.2.1-36.12.1">shadow-4.2.1-36.12.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="shim-15.8-25.30.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:shim-15.8-25.30.1">shim-15.8-25.30.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ng-1.9.0-3.15.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:suseconnect-ng-1.9.0-3.15.4">suseconnect-ng-1.9.0-3.15.4 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ruby-bindings-1.9.0-3.15.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:suseconnect-ruby-bindings-1.9.0-3.15.4">suseconnect-ruby-bindings-1.9.0-3.15.4 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-2.33.2-4.39.14" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:util-linux-2.33.2-4.39.14">util-linux-2.33.2-4.39.14 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-systemd-2.33.2-4.39.12" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:util-linux-systemd-2.33.2-4.39.12">util-linux-systemd-2.33.2-4.39.12 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-9.1.0330-17.33.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:vim-9.1.0330-17.33.1">vim-9.1.0330-17.33.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-data-common-9.1.0330-17.33.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:vim-data-common-9.1.0330-17.33.1">vim-data-common-9.1.0330-17.33.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wget-1.14-21.19.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:wget-1.14-21.19.1">wget-1.14-21.19.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wicked-0.6.75-3.43.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:wicked-0.6.75-3.43.1">wicked-0.6.75-3.43.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wicked-service-0.6.75-3.43.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:wicked-service-0.6.75-3.43.1">wicked-service-0.6.75-3.43.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="xfsprogs-4.15.0-3.21.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:xfsprogs-4.15.0-3.21.2">xfsprogs-4.15.0-3.21.2 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="zypper-1.13.67-21.64.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:zypper-1.13.67-21.64.1">zypper-1.13.67-21.64.1 as a component of Public Cloud Image google/sles-12-sp5-byos-v20240727-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-byos-v20240727-x86-64:shadow-4.2.1-36.12.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">The commandline package update tool zypper writes HTTP proxy credentials into its logfile, allowing local attackers to gain access to proxies used.</Note>
    </Notes>
    <CVE>CVE-2017-9271</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libzypp-16.22.13-65.3</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>2.1</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:P/I:N/A:N</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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-byos-v20240727-x86-64:python-pyOpenSSL-17.1.0-4.26.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python3-pyOpenSSL-17.1.0-4.26.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 the Linux kernel, the following vulnerability has been resolved:

netlabel: fix out-of-bounds memory accesses

There are two array out-of-bounds memory accesses, one in
cipso_v4_map_lvl_valid(), the other in netlbl_bitmap_walk().  Both
errors are embarassingly simple, and the fixes are straightforward.

As a FYI for anyone backporting this patch to kernels prior to v4.8,
you'll want to apply the netlbl_bitmap_walk() patch to
cipso_v4_bitmap_walk() as netlbl_bitmap_walk() doesn't exist before
Linux v4.8.</Note>
    </Notes>
    <CVE>CVE-2019-25160</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Legacy pairing and secure-connections pairing authentication in Bluetooth BR/EDR Core Specification v5.2 and earlier may allow an unauthenticated user to complete authentication without pairing credentials via adjacent access. An unauthenticated, adjacent attacker could impersonate a Bluetooth BR/EDR master or slave to pair with a previously paired remote device to successfully complete the authentication procedure without knowing the link key.</Note>
    </Notes>
    <CVE>CVE-2020-10135</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>4.8</BaseScore>
        <Vector>AV:A/AC:L/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">json-c through 0.14 has an integer overflow and out-of-bounds write via a large JSON file, as demonstrated by printbuf_memappend.</Note>
    </Notes>
    <CVE>CVE-2020-12762</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libfastjson4-0.99.8-3.6.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">An issue was discovered in the Linux kernel before 5.8.10. virt/kvm/kvm_main.c has a kvm_io_bus_unregister_dev memory leak upon a kmalloc failure, aka CID-f65886606c2d.</Note>
    </Notes>
    <CVE>CVE-2020-36312</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>2.1</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:N/I:N/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Use After Free vulnerability in nfc sockets in the Linux Kernel before 5.12.4 allows local attackers to elevate their privileges. In typical configurations, the issue can only be triggered by a privileged local user with the CAP_NET_RAW capability.</Note>
    </Notes>
    <CVE>CVE-2021-23134</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>4.6</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:P/I:P/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was discovered in the Linux kernel before 5.14.15. There is an array-index-out-of-bounds flaw in the detach_capi_ctr function in drivers/isdn/capi/kcapi.c.</Note>
    </Notes>
    <CVE>CVE-2021-43389</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>2.1</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:N/I:N/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ARM: footbridge: fix PCI interrupt mapping

Since commit 30fdfb929e82 ("PCI: Add a call to pci_assign_irq() in
pci_device_probe()"), the PCI code will call the IRQ mapping function
whenever a PCI driver is probed. If these are marked as __init, this
causes an oops if a PCI driver is loaded or bound after the kernel has
initialised.</Note>
    </Notes>
    <CVE>CVE-2021-46909</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear.

ffs_data_clear is indirectly called from both ffs_fs_kill_sb and
ffs_ep0_release, so it ends up being called twice when userland closes ep0
and then unmounts f_fs.
If userland provided an eventfd along with function's USB descriptors, it
ends up calling eventfd_ctx_put as many times, causing a refcount
underflow.
NULL-ify ffs_eventfd to prevent these extraneous eventfd_ctx_put calls.

Also, set epfiles to NULL right after de-allocating it, for readability.

For completeness, ffs_data_clear actually ends up being called thrice, the
last call being before the whole ffs structure gets freed, so when this
specific sequence happens there is a second underflow happening (but not
being reported):

/sys/kernel/debug/tracing# modprobe usb_f_fs
/sys/kernel/debug/tracing# echo ffs_data_clear &gt; set_ftrace_filter
/sys/kernel/debug/tracing# echo function &gt; current_tracer
/sys/kernel/debug/tracing# echo 1 &gt; tracing_on
(setup gadget, run and kill function userland process, teardown gadget)
/sys/kernel/debug/tracing# echo 0 &gt; tracing_on
/sys/kernel/debug/tracing# cat trace
 smartcard-openp-436     [000] .....  1946.208786: ffs_data_clear &lt;-ffs_data_closed
 smartcard-openp-431     [000] .....  1946.279147: ffs_data_clear &lt;-ffs_data_closed
 smartcard-openp-431     [000] .n...  1946.905512: ffs_data_clear &lt;-ffs_data_put

Warning output corresponding to above trace:
[ 1946.284139] WARNING: CPU: 0 PID: 431 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15c
[ 1946.293094] refcount_t: underflow; use-after-free.
[ 1946.298164] Modules linked in: usb_f_ncm(E) u_ether(E) usb_f_fs(E) hci_uart(E) btqca(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) bcm2835_v4l2(CE) bcm2835_mmal_vchiq(CE) videobuf2_vmalloc(E) videobuf2_memops(E) sha512_generic(E) videobuf2_v4l2(E) sha512_arm(E) videobuf2_common(E) videodev(E) cpufreq_dt(E) snd_bcm2835(CE) brcmfmac(E) mc(E) vc4(E) ctr(E) brcmutil(E) snd_soc_core(E) snd_pcm_dmaengine(E) drbg(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) drm_kms_helper(E) cec(E) ansi_cprng(E) rc_core(E) syscopyarea(E) raspberrypi_cpufreq(E) sysfillrect(E) sysimgblt(E) cfg80211(E) max17040_battery(OE) raspberrypi_hwmon(E) fb_sys_fops(E) regmap_i2c(E) ecdh_generic(E) rfkill(E) ecc(E) bcm2835_rng(E) rng_core(E) vchiq(CE) leds_gpio(E) libcomposite(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sdhci_iproc(E) sdhci_pltfm(E) sdhci(E)
[ 1946.399633] CPU: 0 PID: 431 Comm: smartcard-openp Tainted: G         C OE     5.15.0-1-rpi #1  Debian 5.15.3-1
[ 1946.417950] Hardware name: BCM2835
[ 1946.425442] Backtrace:
[ 1946.432048] [&lt;c08d60a0&gt;] (dump_backtrace) from [&lt;c08d62ec&gt;] (show_stack+0x20/0x24)
[ 1946.448226]  r7:00000009 r6:0000001c r5:c04a948c r4:c0a64e2c
[ 1946.458412] [&lt;c08d62cc&gt;] (show_stack) from [&lt;c08d9ae0&gt;] (dump_stack+0x28/0x30)
[ 1946.470380] [&lt;c08d9ab8&gt;] (dump_stack) from [&lt;c0123500&gt;] (__warn+0xe8/0x154)
[ 1946.482067]  r5:c04a948c r4:c0a71dc8
[ 1946.490184] [&lt;c0123418&gt;] (__warn) from [&lt;c08d6948&gt;] (warn_slowpath_fmt+0xa0/0xe4)
[ 1946.506758]  r7:00000009 r6:0000001c r5:c0a71dc8 r4:c0a71e04
[ 1946.517070] [&lt;c08d68ac&gt;] (warn_slowpath_fmt) from [&lt;c04a948c&gt;] (refcount_warn_saturate+0x110/0x15c)
[ 1946.535309]  r8:c0100224 r7:c0dfcb84 r6:ffffffff r5:c3b84c00 r4:c24a17c0
[ 1946.546708] [&lt;c04a937c&gt;] (refcount_warn_saturate) from [&lt;c0380134&gt;] (eventfd_ctx_put+0x48/0x74)
[ 1946.564476] [&lt;c03800ec&gt;] (eventfd_ctx_put) from [&lt;bf5464e8&gt;] (ffs_data_clear+0xd0/0x118 [usb_f_fs])
[ 1946.582664]  r5:c3b84c00 r4:c2695b00
[ 1946.590668] [&lt;bf546418&gt;] (ffs_data_clear [usb_f_fs]) from [&lt;bf547cc0&gt;] (ffs_data_closed+0x9c/0x150 [usb_f_fs])
[ 1946.609608]  r5:bf54d014 r4:c2695b00
[ 1946.617522] [&lt;bf547c24&gt;] (ffs_data_closed [usb_f_fs]) from [&lt;bf547da0&gt;] (ffs_fs_kill_sb+0x2c/0x30 [usb_f_fs])
[ 1946.636217]  r7:c0dfcb
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-46933</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 rq: fix double free of blk_mq_tag_set in dev remove after table load fails

When loading a device-mapper table for a request-based mapped device,
and the allocation/initialization of the blk_mq_tag_set for the device
fails, a following device remove will cause a double free.

E.g. (dmesg):
  device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device
  device-mapper: ioctl: unable to set up device queue for new table.
  Unable to handle kernel pointer dereference in virtual kernel address space
  Failing address: 0305e098835de000 TEID: 0305e098835de803
  Fault in home space mode while using kernel ASCE.
  AS:000000025efe0007 R3:0000000000000024
  Oops: 0038 ilc:3 [#1] SMP
  Modules linked in: ... lots of modules ...
  Supported: Yes, External
  CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G        W      X    5.3.18-53-default #1 SLE15-SP3
  Hardware name: IBM 8561 T01 7I2 (LPAR)
  Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330)
             R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
  Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000
             000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000
             000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640
             00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8
  Krnl Code: 000000025e368eb8: c4180041e100       lgrl    %r1,25eba50b8
             000000025e368ebe: ecba06b93a55       risbg   %r11,%r10,6,185,58
            #000000025e368ec4: e3b010000008       ag      %r11,0(%r1)
            &gt;000000025e368eca: e310b0080004       lg      %r1,8(%r11)
             000000025e368ed0: a7110001           tmll    %r1,1
             000000025e368ed4: a7740129           brc     7,25e369126
             000000025e368ed8: e320b0080004       lg      %r2,8(%r11)
             000000025e368ede: b904001b           lgr     %r1,%r11
  Call Trace:
   [&lt;000000025e368eca&gt;] kfree+0x42/0x330
   [&lt;000000025e5202a2&gt;] blk_mq_free_tag_set+0x72/0xb8
   [&lt;000003ff801316a8&gt;] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod]
   [&lt;000003ff80120082&gt;] free_dev+0x52/0xd0 [dm_mod]
   [&lt;000003ff801233f0&gt;] __dm_destroy+0x150/0x1d0 [dm_mod]
   [&lt;000003ff8012bb9a&gt;] dev_remove+0x162/0x1c0 [dm_mod]
   [&lt;000003ff8012a988&gt;] ctl_ioctl+0x198/0x478 [dm_mod]
   [&lt;000003ff8012ac8a&gt;] dm_ctl_ioctl+0x22/0x38 [dm_mod]
   [&lt;000000025e3b11ee&gt;] ksys_ioctl+0xbe/0xe0
   [&lt;000000025e3b127a&gt;] __s390x_sys_ioctl+0x2a/0x40
   [&lt;000000025e8c15ac&gt;] system_call+0xd8/0x2c8
  Last Breaking-Event-Address:
   [&lt;000000025e52029c&gt;] blk_mq_free_tag_set+0x6c/0xb8
  Kernel panic - not syncing: Fatal exception: panic_on_oops

When allocation/initialization of the blk_mq_tag_set fails in
dm_mq_init_request_queue(), it is uninitialized/freed, but the pointer
is not reset to NULL; so when dev_remove() later gets into
dm_mq_cleanup_mapped_device() it sees the pointer and tries to
uninitialize and free it again.

Fix this by setting the pointer to NULL in dm_mq_init_request_queue()
error-handling. Also set it to NULL in dm_mq_cleanup_mapped_device().</Note>
    </Notes>
    <CVE>CVE-2021-46938</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Restructure trace_clock_global() to never block

It was reported that a fix to the ring buffer recursion detection would
cause a hung machine when performing suspend / resume testing. The
following backtrace was extracted from debugging that case:

Call Trace:
 trace_clock_global+0x91/0xa0
 __rb_reserve_next+0x237/0x460
 ring_buffer_lock_reserve+0x12a/0x3f0
 trace_buffer_lock_reserve+0x10/0x50
 __trace_graph_return+0x1f/0x80
 trace_graph_return+0xb7/0xf0
 ? trace_clock_global+0x91/0xa0
 ftrace_return_to_handler+0x8b/0xf0
 ? pv_hash+0xa0/0xa0
 return_to_handler+0x15/0x30
 ? ftrace_graph_caller+0xa0/0xa0
 ? trace_clock_global+0x91/0xa0
 ? __rb_reserve_next+0x237/0x460
 ? ring_buffer_lock_reserve+0x12a/0x3f0
 ? trace_event_buffer_lock_reserve+0x3c/0x120
 ? trace_event_buffer_reserve+0x6b/0xc0
 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0
 ? dpm_run_callback+0x3b/0xc0
 ? pm_ops_is_empty+0x50/0x50
 ? platform_get_irq_byname_optional+0x90/0x90
 ? trace_device_pm_callback_start+0x82/0xd0
 ? dpm_run_callback+0x49/0xc0

With the following RIP:

RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200

Since the fix to the recursion detection would allow a single recursion to
happen while tracing, this lead to the trace_clock_global() taking a spin
lock and then trying to take it again:

ring_buffer_lock_reserve() {
  trace_clock_global() {
    arch_spin_lock() {
      queued_spin_lock_slowpath() {
        /* lock taken */
        (something else gets traced by function graph tracer)
          ring_buffer_lock_reserve() {
            trace_clock_global() {
              arch_spin_lock() {
                queued_spin_lock_slowpath() {
                /* DEAD LOCK! */

Tracing should *never* block, as it can lead to strange lockups like the
above.

Restructure the trace_clock_global() code to instead of simply taking a
lock to update the recorded "prev_time" simply use it, as two events
happening on two different CPUs that calls this at the same time, really
doesn't matter which one goes first. Use a trylock to grab the lock for
updating the prev_time, and if it fails, simply try again the next time.
If it failed to be taken, that means something else is already updating
it.


Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761</Note>
    </Notes>
    <CVE>CVE-2021-46939</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Do core softreset when switch mode


According to the programming guide, to switch mode for DRD controller,
the driver needs to do the following.

To switch from device to host:
1. Reset controller with GCTL.CoreSoftReset
2. Set GCTL.PrtCapDir(host mode)
3. Reset the host with USBCMD.HCRESET
4. Then follow up with the initializing host registers sequence

To switch from host to device:
1. Reset controller with GCTL.CoreSoftReset
2. Set GCTL.PrtCapDir(device mode)
3. Reset the device with DCTL.CSftRst
4. Then follow up with the initializing registers sequence

Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of
switching from host to device. John Stult reported a lockup issue seen
with HiKey960 platform without these steps[1]. Similar issue is observed
with Ferry's testing platform[2].

So, apply the required steps along with some fixes to Yu Chen's and John
Stultz's version. The main fixes to their versions are the missing wait
for clocks synchronization before clearing GCTL.CoreSoftReset and only
apply DCTL.CSftRst when switching from host to device.

[1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/
[2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/</Note>
    </Notes>
    <CVE>CVE-2021-46941</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

md/raid1: properly indicate failure when ending a failed write request

This patch addresses a data corruption bug in raid1 arrays using bitmaps.
Without this fix, the bitmap bits for the failed I/O end up being cleared.

Since we are in the failure leg of raid1_end_write_request, the request
either needs to be retried (R1BIO_WriteError) or failed (R1BIO_Degraded).</Note>
    </Notes>
    <CVE>CVE-2021-46950</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

openvswitch: fix stack OOB read while fragmenting IPv4 packets

running openvswitch on kernels built with KASAN, it's possible to see the
following splat while testing fragmentation of IPv4 packets:

 BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60
 Read of size 1 at addr ffff888112fc713c by task handler2/1367

 CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418
 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
 Call Trace:
  dump_stack+0x92/0xc1
  print_address_description.constprop.7+0x1a/0x150
  kasan_report.cold.13+0x7f/0x111
  ip_do_fragment+0x1b03/0x1f60
  ovs_fragment+0x5bf/0x840 [openvswitch]
  do_execute_actions+0x1bd5/0x2400 [openvswitch]
  ovs_execute_actions+0xc8/0x3d0 [openvswitch]
  ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch]
  genl_family_rcv_msg_doit.isra.15+0x227/0x2d0
  genl_rcv_msg+0x287/0x490
  netlink_rcv_skb+0x120/0x380
  genl_rcv+0x24/0x40
  netlink_unicast+0x439/0x630
  netlink_sendmsg+0x719/0xbf0
  sock_sendmsg+0xe2/0x110
  ____sys_sendmsg+0x5ba/0x890
  ___sys_sendmsg+0xe9/0x160
  __sys_sendmsg+0xd3/0x170
  do_syscall_64+0x33/0x40
  entry_SYSCALL_64_after_hwframe+0x44/0xae
 RIP: 0033:0x7f957079db07
 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48
 RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
 RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07
 RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019
 RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730
 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
 R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0

 The buggy address belongs to the page:
 page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7
 flags: 0x17ffffc0000000()
 raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000
 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
 page dumped because: kasan: bad access detected

 addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame:
  ovs_fragment+0x0/0x840 [openvswitch]

 this frame has 2 objects:
  [32, 144) 'ovs_dst'
  [192, 424) 'ovs_rt'

 Memory state around the buggy address:
  ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00
 &gt;ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00
                                         ^
  ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00

for IPv4 packets, ovs_fragment() uses a temporary struct dst_entry. Then,
in the following call graph:

  ip_do_fragment()
    ip_skb_dst_mtu()
      ip_dst_mtu_maybe_forward()
        ip_mtu_locked()

the pointer to struct dst_entry is used as pointer to struct rtable: this
turns the access to struct members like rt_mtu_locked into an OOB read in
the stack. Fix this changing the temporary variable used for IPv4 packets
in ovs_fragment(), similarly to what is done for IPv6 few lines below.</Note>
    </Notes>
    <CVE>CVE-2021-46955</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 race between transaction aborts and fsyncs leading to use-after-free

There is a race between a task aborting a transaction during a commit,
a task doing an fsync and the transaction kthread, which leads to an
use-after-free of the log root tree. When this happens, it results in a
stack trace like the following:

  BTRFS info (device dm-0): forced readonly
  BTRFS warning (device dm-0): Skipping commit of aborted transaction.
  BTRFS: error (device dm-0) in cleanup_transaction:1958: errno=-5 IO failure
  BTRFS warning (device dm-0): lost page write due to IO error on /dev/mapper/error-test (-5)
  BTRFS warning (device dm-0): Skipping commit of aborted transaction.
  BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0xa4e8 len 4096 err no 10
  BTRFS error (device dm-0): error writing primary super block to device 1
  BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e000 len 4096 err no 10
  BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e008 len 4096 err no 10
  BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e010 len 4096 err no 10
  BTRFS: error (device dm-0) in write_all_supers:4110: errno=-5 IO failure (1 errors while writing supers)
  BTRFS: error (device dm-0) in btrfs_sync_log:3308: errno=-5 IO failure
  general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b68: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
  CPU: 2 PID: 2458471 Comm: fsstress Not tainted 5.12.0-rc5-btrfs-next-84 #1
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
  RIP: 0010:__mutex_lock+0x139/0xa40
  Code: c0 74 19 (...)
  RSP: 0018:ffff9f18830d7b00 EFLAGS: 00010202
  RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000000001 RCX: 0000000000000002
  RDX: ffffffffb9c54d13 RSI: 0000000000000000 RDI: 0000000000000000
  RBP: ffff9f18830d7bc0 R08: 0000000000000000 R09: 0000000000000000
  R10: ffff9f18830d7be0 R11: 0000000000000001 R12: ffff8c6cd199c040
  R13: ffff8c6c95821358 R14: 00000000fffffffb R15: ffff8c6cbcf01358
  FS:  00007fa9140c2b80(0000) GS:ffff8c6fac600000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007fa913d52000 CR3: 000000013d2b4003 CR4: 0000000000370ee0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   ? __btrfs_handle_fs_error+0xde/0x146 [btrfs]
   ? btrfs_sync_log+0x7c1/0xf20 [btrfs]
   ? btrfs_sync_log+0x7c1/0xf20 [btrfs]
   btrfs_sync_log+0x7c1/0xf20 [btrfs]
   btrfs_sync_file+0x40c/0x580 [btrfs]
   do_fsync+0x38/0x70
   __x64_sys_fsync+0x10/0x20
   do_syscall_64+0x33/0x80
   entry_SYSCALL_64_after_hwframe+0x44/0xae
  RIP: 0033:0x7fa9142a55c3
  Code: 8b 15 09 (...)
  RSP: 002b:00007fff26278d48 EFLAGS: 00000246 ORIG_RAX: 000000000000004a
  RAX: ffffffffffffffda RBX: 0000563c83cb4560 RCX: 00007fa9142a55c3
  RDX: 00007fff26278cb0 RSI: 00007fff26278cb0 RDI: 0000000000000005
  RBP: 0000000000000005 R08: 0000000000000001 R09: 00007fff26278d5c
  R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000340
  R13: 00007fff26278de0 R14: 00007fff26278d96 R15: 0000563c83ca57c0
  Modules linked in: btrfs dm_zero dm_snapshot dm_thin_pool (...)
  ---[ end trace ee2f1b19327d791d ]---

The steps that lead to this crash are the following:

1) We are at transaction N;

2) We have two tasks with a transaction handle attached to transaction N.
   Task A and Task B. Task B is doing an fsync;

3) Task B is at btrfs_sync_log(), and has saved fs_info-&gt;log_root_tree
   into a local variable named 'log_root_tree' at the top of
   btrfs_sync_log(). Task B is about to call write_all_supers(), but
   before that...

4) Task A calls btrfs_commit_transaction(), and after it sets the
   transaction state to TRANS_STATE_COMMIT_START, an error happens before
   it w
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-46958</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Return correct error code from smb2_get_enc_key

Avoid a warning if the error percolates back up:

[440700.376476] CIFS VFS: \\otters.example.com crypt_message: Could not get encryption key
[440700.386947] ------------[ cut here ]------------
[440700.386948] err = 1
[440700.386977] WARNING: CPU: 11 PID: 2733 at /build/linux-hwe-5.4-p6lk6L/linux-hwe-5.4-5.4.0/lib/errseq.c:74 errseq_set+0x5c/0x70
...
[440700.397304] CPU: 11 PID: 2733 Comm: tar Tainted: G           OE     5.4.0-70-generic #78~18.04.1-Ubuntu
...
[440700.397334] Call Trace:
[440700.397346]  __filemap_set_wb_err+0x1a/0x70
[440700.397419]  cifs_writepages+0x9c7/0xb30 [cifs]
[440700.397426]  do_writepages+0x4b/0xe0
[440700.397444]  __filemap_fdatawrite_range+0xcb/0x100
[440700.397455]  filemap_write_and_wait+0x42/0xa0
[440700.397486]  cifs_setattr+0x68b/0xf30 [cifs]
[440700.397493]  notify_change+0x358/0x4a0
[440700.397500]  utimes_common+0xe9/0x1c0
[440700.397510]  do_utimes+0xc5/0x150
[440700.397520]  __x64_sys_utimensat+0x88/0xd0</Note>
    </Notes>
    <CVE>CVE-2021-46960</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 crash in qla2xxx_mqueuecommand()

    RIP: 0010:kmem_cache_free+0xfa/0x1b0
    Call Trace:
       qla2xxx_mqueuecommand+0x2b5/0x2c0 [qla2xxx]
       scsi_queue_rq+0x5e2/0xa40
       __blk_mq_try_issue_directly+0x128/0x1d0
       blk_mq_request_issue_directly+0x4e/0xb0

Fix incorrect call to free srb in qla2xxx_mqueuecommand(), as srb is now
allocated by upper layers. This fixes smatch warning of srb unintended
free.</Note>
    </Notes>
    <CVE>CVE-2021-46963</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Reserve extra IRQ vectors

Commit a6dcfe08487e ("scsi: qla2xxx: Limit interrupt vectors to number of
CPUs") lowers the number of allocated MSI-X vectors to the number of CPUs.

That breaks vector allocation assumptions in qla83xx_iospace_config(),
qla24xx_enable_msix() and qla2x00_iospace_config(). Either of the functions
computes maximum number of qpairs as:

  ha-&gt;max_qpairs = ha-&gt;msix_count - 1 (MB interrupt) - 1 (default
                   response queue) - 1 (ATIO, in dual or pure target mode)

max_qpairs is set to zero in case of two CPUs and initiator mode. The
number is then used to allocate ha-&gt;queue_pair_map inside
qla2x00_alloc_queues(). No allocation happens and ha-&gt;queue_pair_map is
left NULL but the driver thinks there are queue pairs available.

qla2xxx_queuecommand() tries to find a qpair in the map and crashes:

  if (ha-&gt;mqenable) {
          uint32_t tag;
          uint16_t hwq;
          struct qla_qpair *qpair = NULL;

          tag = blk_mq_unique_tag(cmd-&gt;request);
          hwq = blk_mq_unique_tag_to_hwq(tag);
          qpair = ha-&gt;queue_pair_map[hwq]; # &lt;- HERE

          if (qpair)
                  return qla2xxx_mqueuecommand(host, cmd, qpair);
  }

  BUG: kernel NULL pointer dereference, address: 0000000000000000
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP PTI
  CPU: 0 PID: 72 Comm: kworker/u4:3 Tainted: G        W         5.10.0-rc1+ #25
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
  Workqueue: scsi_wq_7 fc_scsi_scan_rport [scsi_transport_fc]
  RIP: 0010:qla2xxx_queuecommand+0x16b/0x3f0 [qla2xxx]
  Call Trace:
   scsi_queue_rq+0x58c/0xa60
   blk_mq_dispatch_rq_list+0x2b7/0x6f0
   ? __sbitmap_get_word+0x2a/0x80
   __blk_mq_sched_dispatch_requests+0xb8/0x170
   blk_mq_sched_dispatch_requests+0x2b/0x50
   __blk_mq_run_hw_queue+0x49/0xb0
   __blk_mq_delay_run_hw_queue+0xfb/0x150
   blk_mq_sched_insert_request+0xbe/0x110
   blk_execute_rq+0x45/0x70
   __scsi_execute+0x10e/0x250
   scsi_probe_and_add_lun+0x228/0xda0
   __scsi_scan_target+0xf4/0x620
   ? __pm_runtime_resume+0x4f/0x70
   scsi_scan_target+0x100/0x110
   fc_scsi_scan_rport+0xa1/0xb0 [scsi_transport_fc]
   process_one_work+0x1ea/0x3b0
   worker_thread+0x28/0x3b0
   ? process_one_work+0x3b0/0x3b0
   kthread+0x112/0x130
   ? kthread_park+0x80/0x80
   ret_from_fork+0x22/0x30

The driver should allocate enough vectors to provide every CPU it's own HW
queue and still handle reserved (MB, RSP, ATIO) interrupts.

The change fixes the crash on dual core VM and prevents unbalanced QP
allocation where nr_hw_queues is two less than the number of CPUs.</Note>
    </Notes>
    <CVE>CVE-2021-46964</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: custom_method: fix potential use-after-free issue

In cm_write(), buf is always freed when reaching the end of the
function.  If the requested count is less than table.length, the
allocated buffer will be freed but subsequent calls to cm_write() will
still try to access it.

Remove the unconditional kfree(buf) at the end of the function and
set the buf to NULL in the -EINVAL error path to match the rest of
function.</Note>
    </Notes>
    <CVE>CVE-2021-46966</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix NULL pointer in flush_workqueue

Open /dev/nbdX first, the config_refs will be 1 and
the pointers in nbd_device are still null. Disconnect
/dev/nbdX, then reference a null recv_workq. The
protection by config_refs in nbd_genl_disconnect is useless.

[  656.366194] BUG: kernel NULL pointer dereference, address: 0000000000000020
[  656.368943] #PF: supervisor write access in kernel mode
[  656.369844] #PF: error_code(0x0002) - not-present page
[  656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0
[  656.371693] Oops: 0002 [#1] SMP
[  656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 5.11.0-rc5-00040-g76c057c84d28 #1
[  656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
[  656.375904] RIP: 0010:mutex_lock+0x29/0x60
[  656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 &lt;f0&gt; 48 0f b1 55 d
[  656.378934] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246
[  656.379350] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[  656.379915] RDX: ffff888104cf2600 RSI: ffffffffaae8f452 RDI: 0000000000000020
[  656.380473] RBP: 0000000000000020 R08: 0000000000000000 R09: ffff88813bd6b318
[  656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40
[  656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00
[  656.382166] FS:  00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000
[  656.382806] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0
[  656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  656.384927] Call Trace:
[  656.385111]  flush_workqueue+0x92/0x6c0
[  656.385395]  nbd_disconnect_and_put+0x81/0xd0
[  656.385716]  nbd_genl_disconnect+0x125/0x2a0
[  656.386034]  genl_family_rcv_msg_doit.isra.0+0x102/0x1b0
[  656.386422]  genl_rcv_msg+0xfc/0x2b0
[  656.386685]  ? nbd_ioctl+0x490/0x490
[  656.386954]  ? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0
[  656.387354]  netlink_rcv_skb+0x62/0x180
[  656.387638]  genl_rcv+0x34/0x60
[  656.387874]  netlink_unicast+0x26d/0x590
[  656.388162]  netlink_sendmsg+0x398/0x6c0
[  656.388451]  ? netlink_rcv_skb+0x180/0x180
[  656.388750]  ____sys_sendmsg+0x1da/0x320
[  656.389038]  ? ____sys_recvmsg+0x130/0x220
[  656.389334]  ___sys_sendmsg+0x8e/0xf0
[  656.389605]  ? ___sys_recvmsg+0xa2/0xf0
[  656.389889]  ? handle_mm_fault+0x1671/0x21d0
[  656.390201]  __sys_sendmsg+0x6d/0xe0
[  656.390464]  __x64_sys_sendmsg+0x23/0x30
[  656.390751]  do_syscall_64+0x45/0x70
[  656.391017]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

To fix it, just add if (nbd-&gt;recv_workq) to nbd_disconnect_and_put().</Note>
    </Notes>
    <CVE>CVE-2021-46981</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: release page in error path to avoid BUG_ON

Consider the following sequence of events:

1. Userspace issues a UFFD ioctl, which ends up calling into
   shmem_mfill_atomic_pte(). We successfully account the blocks, we
   shmem_alloc_page(), but then the copy_from_user() fails. We return
   -ENOENT. We don't release the page we allocated.
2. Our caller detects this error code, tries the copy_from_user() after
   dropping the mmap_lock, and retries, calling back into
   shmem_mfill_atomic_pte().
3. Meanwhile, let's say another process filled up the tmpfs being used.
4. So shmem_mfill_atomic_pte() fails to account blocks this time, and
   immediately returns - without releasing the page.

This triggers a BUG_ON in our caller, which asserts that the page
should always be consumed, unless -ENOENT is returned.

To fix this, detect if we have such a "dangling" page when accounting
fails, and if so, release it before returning.</Note>
    </Notes>
    <CVE>CVE-2021-46988</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/64s: Fix crashes when toggling entry flush barrier

The entry flush mitigation can be enabled/disabled at runtime via a
debugfs file (entry_flush), which causes the kernel to patch itself to
enable/disable the relevant mitigations.

However depending on which mitigation we're using, it may not be safe to
do that patching while other CPUs are active. For example the following
crash:

  sleeper[15639]: segfault (11) at c000000000004c20 nip c000000000004c20 lr c000000000004c20

Shows that we returned to userspace with a corrupted LR that points into
the kernel, due to executing the partially patched call to the fallback
entry flush (ie. we missed the LR restore).

Fix it by doing the patching under stop machine. The CPUs that aren't
doing the patching will be spinning in the core of the stop machine
logic. That is currently sufficient for our purposes, because none of
the patching we do is to that code or anywhere in the vicinity.</Note>
    </Notes>
    <CVE>CVE-2021-46990</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:enic: Fix a use after free bug in enic_hard_start_xmit

In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside
enic_queue_wq_skb, if some error happens, the skb will be freed
by dev_kfree_skb(skb). But the freed skb is still used in
skb_tx_timestamp(skb).

My patch makes enic_queue_wq_skb() return error and goto spin_unlock()
incase of error. The solution is provided by Govind.
See https://lkml.org/lkml/2021/4/30/961.</Note>
    </Notes>
    <CVE>CVE-2021-46998</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ARM: 9064/1: hw_breakpoint: Do not directly check the event's overflow_handler hook

The commit 1879445dfa7b ("perf/core: Set event's default
::overflow_handler()") set a default event-&gt;overflow_handler in
perf_event_alloc(), and replace the check event-&gt;overflow_handler with
is_default_overflow_handler(), but one is missing.

Currently, the bp-&gt;overflow_handler can not be NULL. As a result,
enable_single_step() is always not invoked.

Comments from Zhen Lei:

 https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210207105934.2001-1-thunder.leizhen@huawei.com/</Note>
    </Notes>
    <CVE>CVE-2021-47006</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bnxt_en: Fix RX consumer index logic in the error path.

In bnxt_rx_pkt(), the RX buffers are expected to complete in order.
If the RX consumer index indicates an out of order buffer completion,
it means we are hitting a hardware bug and the driver will abort all
remaining RX packets and reset the RX ring.  The RX consumer index
that we pass to bnxt_discard_rx() is not correct.  We should be
passing the current index (tmp_raw_cons) instead of the old index
(raw_cons).  This bug can cause us to be at the wrong index when
trying to abort the next RX packet.  It can crash like this:

 #0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007
 #1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232
 #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e
 #3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978
 #4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0
 #5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e
 #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24
 #7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e
 #8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12
 #9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5
    [exception RIP: bnxt_rx_pkt+237]
    RIP: ffffffffc0259cdd  RSP: ffff9bbcdf5c3d98  RFLAGS: 00010213
    RAX: 000000005dd8097f  RBX: ffff9ba4cb11b7e0  RCX: ffffa923cf6e9000
    RDX: 0000000000000fff  RSI: 0000000000000627  RDI: 0000000000001000
    RBP: ffff9bbcdf5c3e60   R8: 0000000000420003   R9: 000000000000020d
    R10: ffffa923cf6ec138  R11: ffff9bbcdf5c3e83  R12: ffff9ba4d6f928c0
    R13: ffff9ba4cac28080  R14: ffff9ba4cb11b7f0  R15: ffff9ba4d5a30000
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018</Note>
    </Notes>
    <CVE>CVE-2021-47015</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: free queued packets when closing socket

As reported by syzbot [1], there is a memory leak while closing the
socket. We partially solved this issue with commit ac03046ece2b
("vsock/virtio: free packets during the socket release"), but we
forgot to drain the RX queue when the socket is definitely closed by
the scheduled work.

To avoid future issues, let's use the new virtio_transport_remove_sock()
to drain the RX queue before removing the socket from the af_vsock lists
calling vsock_remove_sock().

[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9</Note>
    </Notes>
    <CVE>CVE-2021-47024</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/64s: Fix pte update for kernel memory on radix

When adding a PTE a ptesync is needed to order the update of the PTE
with subsequent accesses otherwise a spurious fault may be raised.

radix__set_pte_at() does not do this for performance gains. For
non-kernel memory this is not an issue as any faults of this kind are
corrected by the page fault handler. For kernel memory these faults
are not handled. The current solution is that there is a ptesync in
flush_cache_vmap() which should be called when mapping from the
vmalloc region.

However, map_kernel_page() does not call flush_cache_vmap(). This is
troublesome in particular for code patching with Strict RWX on radix.
In do_patch_instruction() the page frame that contains the instruction
to be patched is mapped and then immediately patched. With no ordering
or synchronization between setting up the PTE and writing to the page
it is possible for faults.

As the code patching is done using __put_user_asm_goto() the resulting
fault is obscured - but using a normal store instead it can be seen:

  BUG: Unable to handle kernel data access on write at 0xc008000008f24a3c
  Faulting instruction address: 0xc00000000008bd74
  Oops: Kernel access of bad area, sig: 11 [#1]
  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
  Modules linked in: nop_module(PO+) [last unloaded: nop_module]
  CPU: 4 PID: 757 Comm: sh Tainted: P           O      5.10.0-rc5-01361-ge3c1b78c8440-dirty #43
  NIP:  c00000000008bd74 LR: c00000000008bd50 CTR: c000000000025810
  REGS: c000000016f634a0 TRAP: 0300   Tainted: P           O       (5.10.0-rc5-01361-ge3c1b78c8440-dirty)
  MSR:  9000000000009033 &lt;SF,HV,EE,ME,IR,DR,RI,LE&gt;  CR: 44002884  XER: 00000000
  CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: 42000000 IRQMASK: 1

This results in the kind of issue reported here:
  https://lore.kernel.org/linuxppc-dev/15AC5B0E-A221-4B8C-9039-FA96B8EF7C88@lca.pw/

Chris Riedl suggested a reliable way to reproduce the issue:
  $ mount -t debugfs none /sys/kernel/debug
  $ (while true; do echo function &gt; /sys/kernel/debug/tracing/current_tracer ; echo nop &gt; /sys/kernel/debug/tracing/current_tracer ; done) &amp;

Turning ftrace on and off does a large amount of code patching which
in usually less then 5min will crash giving a trace like:

   ftrace-powerpc: (____ptrval____): replaced (4b473b11) != old (60000000)
   ------------[ ftrace bug ]------------
   ftrace failed to modify
   [&lt;c000000000bf8e5c&gt;] napi_busy_loop+0xc/0x390
    actual:   11:3b:47:4b
   Setting ftrace call site to call ftrace function
   ftrace record flags: 80000001
    (1)
    expected tramp: c00000000006c96c
   ------------[ cut here ]------------
   WARNING: CPU: 4 PID: 809 at kernel/trace/ftrace.c:2065 ftrace_bug+0x28c/0x2e8
   Modules linked in: nop_module(PO-) [last unloaded: nop_module]
   CPU: 4 PID: 809 Comm: sh Tainted: P           O      5.10.0-rc5-01360-gf878ccaf250a #1
   NIP:  c00000000024f334 LR: c00000000024f330 CTR: c0000000001a5af0
   REGS: c000000004c8b760 TRAP: 0700   Tainted: P           O       (5.10.0-rc5-01360-gf878ccaf250a)
   MSR:  900000000282b033 &lt;SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE&gt;  CR: 28008848  XER: 20040000
   CFAR: c0000000001a9c98 IRQMASK: 0
   GPR00: c00000000024f330 c000000004c8b9f0 c000000002770600 0000000000000022
   GPR04: 00000000ffff7fff c000000004c8b6d0 0000000000000027 c0000007fe9bcdd8
   GPR08: 0000000000000023 ffffffffffffffd8 0000000000000027 c000000002613118
   GPR12: 0000000000008000 c0000007fffdca00 0000000000000000 0000000000000000
   GPR16: 0000000023ec37c5 0000000000000000 0000000000000000 0000000000000008
   GPR20: c000000004c8bc90 c0000000027a2d20 c000000004c8bcd0 c000000002612fe8
   GPR24: 0000000000000038 0000000000000030 0000000000000028 0000000000000020
   GPR28: c000000000ff1b68 c000000000bf8e5c c00000000312f700 c000000000fbb9b0
   NIP ftrace_bug+0x28c/0x2e8
   LR  ftrace_bug+0x288/0x2e8
   Call T
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47034</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Fix null pointer dereference in lpfc_prep_els_iocb()

It is possible to call lpfc_issue_els_plogi() passing a did for which no
matching ndlp is found. A call is then made to lpfc_prep_els_iocb() with a
null pointer to a lpfc_nodelist structure resulting in a null pointer
dereference.

Fix by returning an error status if no valid ndlp is found. Fix up comments
regarding ndlp reference counting.</Note>
    </Notes>
    <CVE>CVE-2021-47045</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Use after free in __vmbus_open()

The "open_info" variable is added to the &amp;vmbus_connection.chn_msg_list,
but the error handling frees "open_info" without removing it from the
list.  This will result in a use after free.  First remove it from the
list, and then free it.</Note>
    </Notes>
    <CVE>CVE-2021-47049</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mtd: require write permissions for locking and badblock ioctls

MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require
write permission. Depending on the hardware MEMLOCK might even be
write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK
is always write-once.

MEMSETBADBLOCK modifies the bad block table.</Note>
    </Notes>
    <CVE>CVE-2021-47055</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init

ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown()
before calling adf_iov_putmsg()-&gt;mutex_lock(vf2pf_lock), however the
vf2pf_lock is initialized in adf_dev_init(), which can fail and when it
fail, the vf2pf_lock is either not initialized or destroyed, a subsequent
use of vf2pf_lock will cause issue.
To fix this issue, only set this flag if adf_dev_init() returns 0.

[    7.178404] BUG: KASAN: user-memory-access in __mutex_lock.isra.0+0x1ac/0x7c0
[    7.180345] Call Trace:
[    7.182576]  mutex_lock+0xc9/0xd0
[    7.183257]  adf_iov_putmsg+0x118/0x1a0 [intel_qat]
[    7.183541]  adf_vf2pf_shutdown+0x4d/0x7b [intel_qat]
[    7.183834]  adf_dev_shutdown+0x172/0x2b0 [intel_qat]
[    7.184127]  adf_probe+0x5e9/0x600 [qat_dh895xccvf]</Note>
    </Notes>
    <CVE>CVE-2021-47056</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm: bridge/panel: Cleanup connector on bridge detach

If we don't call drm_connector_cleanup() manually in
panel_bridge_detach(), the connector will be cleaned up with the other
DRM objects in the call to drm_mode_config_cleanup(). However, since our
drm_connector is devm-allocated, by the time drm_mode_config_cleanup()
will be called, our connector will be long gone. Therefore, the
connector must be cleaned up when the bridge is detached to avoid
use-after-free conditions.

v2: Cleanup connector only if it was created

v3: Add FIXME

v4: (Use connector-&gt;dev) directly in if() block</Note>
    </Notes>
    <CVE>CVE-2021-47063</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 another memory leak in error handling paths

Memory allocated by 'vmbus_alloc_ring()' at the beginning of the probe
function is never freed in the error handling path.

Add the missing 'vmbus_free_ring()' call.

Note that it is already freed in the .remove function.</Note>
    </Notes>
    <CVE>CVE-2021-47070</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 a memory leak in error handling paths

If 'vmbus_establish_gpadl()' fails, the (recv|send)_gpadl will not be
updated and 'hv_uio_cleanup()' in the error handling path will not be
able to free the corresponding buffer.

In such a case, we need to free the buffer explicitly.</Note>
    </Notes>
    <CVE>CVE-2021-47071</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

platform/x86: dell-smbios-wmi: Fix oops on rmmod dell_smbios

init_dell_smbios_wmi() only registers the dell_smbios_wmi_driver on systems
where the Dell WMI interface is supported. While exit_dell_smbios_wmi()
unregisters it unconditionally, this leads to the following oops:

[  175.722921] ------------[ cut here ]------------
[  175.722925] Unexpected driver unregister!
[  175.722939] WARNING: CPU: 1 PID: 3630 at drivers/base/driver.c:194 driver_unregister+0x38/0x40
...
[  175.723089] Call Trace:
[  175.723094]  cleanup_module+0x5/0xedd [dell_smbios]
...
[  175.723148] ---[ end trace 064c34e1ad49509d ]---

Make the unregister happen on the same condition the register happens
to fix this.</Note>
    </Notes>
    <CVE>CVE-2021-47073</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-loop: fix memory leak in nvme_loop_create_ctrl()

When creating loop ctrl in nvme_loop_create_ctrl(), if nvme_init_ctrl()
fails, the loop ctrl should be freed before jumping to the "out" label.</Note>
    </Notes>
    <CVE>CVE-2021-47074</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipmi: Fix UAF when uninstall ipmi_si and ipmi_msghandler module

Hi,

When testing install and uninstall of ipmi_si.ko and ipmi_msghandler.ko,
the system crashed.

The log as follows:
[  141.087026] BUG: unable to handle kernel paging request at ffffffffc09b3a5a
[  141.087241] PGD 8fe4c0d067 P4D 8fe4c0d067 PUD 8fe4c0f067 PMD 103ad89067 PTE 0
[  141.087464] Oops: 0010 [#1] SMP NOPTI
[  141.087580] CPU: 67 PID: 668 Comm: kworker/67:1 Kdump: loaded Not tainted 4.18.0.x86_64 #47
[  141.088009] Workqueue: events 0xffffffffc09b3a40
[  141.088009] RIP: 0010:0xffffffffc09b3a5a
[  141.088009] Code: Bad RIP value.
[  141.088009] RSP: 0018:ffffb9094e2c3e88 EFLAGS: 00010246
[  141.088009] RAX: 0000000000000000 RBX: ffff9abfdb1f04a0 RCX: 0000000000000000
[  141.088009] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
[  141.088009] RBP: 0000000000000000 R08: ffff9abfffee3cb8 R09: 00000000000002e1
[  141.088009] R10: ffffb9094cb73d90 R11: 00000000000f4240 R12: ffff9abfffee8700
[  141.088009] R13: 0000000000000000 R14: ffff9abfdb1f04a0 R15: ffff9abfdb1f04a8
[  141.088009] FS:  0000000000000000(0000) GS:ffff9abfffec0000(0000) knlGS:0000000000000000
[  141.088009] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  141.088009] CR2: ffffffffc09b3a30 CR3: 0000008fe4c0a001 CR4: 00000000007606e0
[  141.088009] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  141.088009] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  141.088009] PKRU: 55555554
[  141.088009] Call Trace:
[  141.088009]  ? process_one_work+0x195/0x390
[  141.088009]  ? worker_thread+0x30/0x390
[  141.088009]  ? process_one_work+0x390/0x390
[  141.088009]  ? kthread+0x10d/0x130
[  141.088009]  ? kthread_flush_work_fn+0x10/0x10
[  141.088009]  ? ret_from_fork+0x35/0x40] BUG: unable to handle kernel paging request at ffffffffc0b28a5a
[  200.223240] PGD 97fe00d067 P4D 97fe00d067 PUD 97fe00f067 PMD a580cbf067 PTE 0
[  200.223464] Oops: 0010 [#1] SMP NOPTI
[  200.223579] CPU: 63 PID: 664 Comm: kworker/63:1 Kdump: loaded Not tainted 4.18.0.x86_64 #46
[  200.224008] Workqueue: events 0xffffffffc0b28a40
[  200.224008] RIP: 0010:0xffffffffc0b28a5a
[  200.224008] Code: Bad RIP value.
[  200.224008] RSP: 0018:ffffbf3c8e2a3e88 EFLAGS: 00010246
[  200.224008] RAX: 0000000000000000 RBX: ffffa0799ad6bca0 RCX: 0000000000000000
[  200.224008] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
[  200.224008] RBP: 0000000000000000 R08: ffff9fe43fde3cb8 R09: 00000000000000d5
[  200.224008] R10: ffffbf3c8cb53d90 R11: 00000000000f4240 R12: ffff9fe43fde8700
[  200.224008] R13: 0000000000000000 R14: ffffa0799ad6bca0 R15: ffffa0799ad6bca8
[  200.224008] FS:  0000000000000000(0000) GS:ffff9fe43fdc0000(0000) knlGS:0000000000000000
[  200.224008] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  200.224008] CR2: ffffffffc0b28a30 CR3: 00000097fe00a002 CR4: 00000000007606e0
[  200.224008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  200.224008] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  200.224008] PKRU: 55555554
[  200.224008] Call Trace:
[  200.224008]  ? process_one_work+0x195/0x390
[  200.224008]  ? worker_thread+0x30/0x390
[  200.224008]  ? process_one_work+0x390/0x390
[  200.224008]  ? kthread+0x10d/0x130
[  200.224008]  ? kthread_flush_work_fn+0x10/0x10
[  200.224008]  ? ret_from_fork+0x35/0x40
[  200.224008] kernel fault(0x1) notification starting on CPU 63
[  200.224008] kernel fault(0x1) notification finished on CPU 63
[  200.224008] CR2: ffffffffc0b28a5a
[  200.224008] ---[ end trace c82a412d93f57412 ]---

The reason is as follows:
T1: rmmod ipmi_si.
    -&gt;ipmi_unregister_smi()
        -&gt; ipmi_bmc_unregister()
            -&gt; __ipmi_bmc_unregister()
                -&gt; kref_put(&amp;bmc-&gt;usecount, cleanup_bmc_device);
                    -&gt; schedule_work(&amp;bmc-&gt;remove_work);

T2: rmmod ipmi_msghandl
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47100</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

asix: fix uninit-value in asix_mdio_read()

asix_read_cmd() may read less than sizeof(smsr) bytes and in this case
smsr will be uninitialized.

Fail log:
BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]
BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497
BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497
 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]
 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497
 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497</Note>
    </Notes>
    <CVE>CVE-2021-47101</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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:

inet: fully convert sk-&gt;sk_rx_dst to RCU rules

syzbot reported various issues around early demux,
one being included in this changelog [1]

sk-&gt;sk_rx_dst is using RCU protection without clearly
documenting it.

And following sequences in tcp_v4_do_rcv()/tcp_v6_do_rcv()
are not following standard RCU rules.

[a]    dst_release(dst);
[b]    sk-&gt;sk_rx_dst = NULL;

They look wrong because a delete operation of RCU protected
pointer is supposed to clear the pointer before
the call_rcu()/synchronize_rcu() guarding actual memory freeing.

In some cases indeed, dst could be freed before [b] is done.

We could cheat by clearing sk_rx_dst before calling
dst_release(), but this seems the right time to stick
to standard RCU annotations and debugging facilities.

[1]
BUG: KASAN: use-after-free in dst_check include/net/dst.h:470 [inline]
BUG: KASAN: use-after-free in tcp_v4_early_demux+0x95b/0x960 net/ipv4/tcp_ipv4.c:1792
Read of size 2 at addr ffff88807f1cb73a by task syz-executor.5/9204

CPU: 0 PID: 9204 Comm: syz-executor.5 Not tainted 5.16.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
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/0x320 mm/kasan/report.c:247
 __kasan_report mm/kasan/report.c:433 [inline]
 kasan_report.cold+0x83/0xdf mm/kasan/report.c:450
 dst_check include/net/dst.h:470 [inline]
 tcp_v4_early_demux+0x95b/0x960 net/ipv4/tcp_ipv4.c:1792
 ip_rcv_finish_core.constprop.0+0x15de/0x1e80 net/ipv4/ip_input.c:340
 ip_list_rcv_finish.constprop.0+0x1b2/0x6e0 net/ipv4/ip_input.c:583
 ip_sublist_rcv net/ipv4/ip_input.c:609 [inline]
 ip_list_rcv+0x34e/0x490 net/ipv4/ip_input.c:644
 __netif_receive_skb_list_ptype net/core/dev.c:5508 [inline]
 __netif_receive_skb_list_core+0x549/0x8e0 net/core/dev.c:5556
 __netif_receive_skb_list net/core/dev.c:5608 [inline]
 netif_receive_skb_list_internal+0x75e/0xd80 net/core/dev.c:5699
 gro_normal_list net/core/dev.c:5853 [inline]
 gro_normal_list net/core/dev.c:5849 [inline]
 napi_complete_done+0x1f1/0x880 net/core/dev.c:6590
 virtqueue_napi_complete drivers/net/virtio_net.c:339 [inline]
 virtnet_poll+0xca2/0x11b0 drivers/net/virtio_net.c:1557
 __napi_poll+0xaf/0x440 net/core/dev.c:7023
 napi_poll net/core/dev.c:7090 [inline]
 net_rx_action+0x801/0xb40 net/core/dev.c:7177
 __do_softirq+0x29b/0x9c2 kernel/softirq.c:558
 invoke_softirq kernel/softirq.c:432 [inline]
 __irq_exit_rcu+0x123/0x180 kernel/softirq.c:637
 irq_exit_rcu+0x5/0x20 kernel/softirq.c:649
 common_interrupt+0x52/0xc0 arch/x86/kernel/irq.c:240
 asm_common_interrupt+0x1e/0x40 arch/x86/include/asm/idtentry.h:629
RIP: 0033:0x7f5e972bfd57
Code: 39 d1 73 14 0f 1f 80 00 00 00 00 48 8b 50 f8 48 83 e8 08 48 39 ca 77 f3 48 39 c3 73 3e 48 89 13 48 8b 50 f8 48 89 38 49 8b 0e &lt;48&gt; 8b 3e 48 83 c3 08 48 83 c6 08 eb bc 48 39 d1 72 9e 48 39 d0 73
RSP: 002b:00007fff8a413210 EFLAGS: 00000283
RAX: 00007f5e97108990 RBX: 00007f5e97108338 RCX: ffffffff81d3aa45
RDX: ffffffff81d3aa45 RSI: 00007f5e97108340 RDI: ffffffff81d3aa45
RBP: 00007f5e97107eb8 R08: 00007f5e97108d88 R09: 0000000093c2e8d9
R10: 0000000000000000 R11: 0000000000000000 R12: 00007f5e97107eb0
R13: 00007f5e97108338 R14: 00007f5e97107ea8 R15: 0000000000000019
 &lt;/TASK&gt;

Allocated by task 13:
 kasan_save_stack+0x1e/0x50 mm/kasan/common.c:38
 kasan_set_track mm/kasan/common.c:46 [inline]
 set_alloc_info mm/kasan/common.c:434 [inline]
 __kasan_slab_alloc+0x90/0xc0 mm/kasan/common.c:467
 kasan_slab_alloc include/linux/kasan.h:259 [inline]
 slab_post_alloc_hook mm/slab.h:519 [inline]
 slab_alloc_node mm/slub.c:3234 [inline]
 slab_alloc mm/slub.c:3242 [inline]
 kmem_cache_alloc+0x202/0x3a0 mm/slub.c:3247
 dst_alloc+0x146/0x1f0 net/core/dst.c:92
 rt_dst_alloc+0x73/0x430 net/ipv4/route.c:1613
 ip_route_input_slow+0x1817/0x3a20 net/ipv4/route.c:234
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47103</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/qib: Fix memory leak in qib_user_sdma_queue_pkts()

The wrong goto label was used for the error case and missed cleanup of the
pkt allocation.

Addresses-Coverity-ID: 1493352 ("Resource leak")</Note>
    </Notes>
    <CVE>CVE-2021-47104</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/kvm: Disable kvmclock on all CPUs on shutdown

Currenly, we disable kvmclock from machine_shutdown() hook and this
only happens for boot CPU. We need to disable it for all CPUs to
guard against memory corruption e.g. on restore from hibernate.

Note, writing '0' to kvmclock MSR doesn't clear memory location, it
just prevents hypervisor from updating the location so for the short
while after write and while CPU is still alive, the clock remains usable
and correct so we don't need to switch to some other clocksource.</Note>
    </Notes>
    <CVE>CVE-2021-47110</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/kvm: Teardown PV features on boot CPU as well

Various PV features (Async PF, PV EOI, steal time) work through memory
shared with hypervisor and when we restore from hibernation we must
properly teardown all these features to make sure hypervisor doesn't
write to stale locations after we jump to the previously hibernated kernel
(which can try to place anything there). For secondary CPUs the job is
already done by kvm_cpu_down_prepare(), register syscore ops to do
the same for boot CPU.</Note>
    </Notes>
    <CVE>CVE-2021-47112</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: abort in rename_exchange if we fail to insert the second ref

Error injection stress uncovered a problem where we'd leave a dangling
inode ref if we failed during a rename_exchange.  This happens because
we insert the inode ref for one side of the rename, and then for the
other side.  If this second inode ref insert fails we'll leave the first
one dangling and leave a corrupt file system behind.  Fix this by
aborting if we did the insert for the first inode ref.</Note>
    </Notes>
    <CVE>CVE-2021-47113</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 data corruption by fallocate

When fallocate punches holes out of inode size, if original isize is in
the middle of last cluster, then the part from isize to the end of the
cluster will be zeroed with buffer write, at that time isize is not yet
updated to match the new size, if writeback is kicked in, it will invoke
ocfs2_writepage()-&gt;block_write_full_page() where the pages out of inode
size will be dropped.  That will cause file corruption.  Fix this by
zero out eof blocks when extending the inode size.

Running the following command with qemu-image 4.2.1 can get a corrupted
coverted image file easily.

    qemu-img convert -p -t none -T none -f qcow2 $qcow_image \
             -O qcow2 -o compat=1.1 $qcow_image.conv

The usage of fallocate in qemu is like this, it first punches holes out
of inode size, then extend the inode size.

    fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2276196352, 65536) = 0
    fallocate(11, 0, 2276196352, 65536) = 0

v1: https://www.spinics.net/lists/linux-fsdevel/msg193999.html
v2: https://lore.kernel.org/linux-fsdevel/20210525093034.GB4112@quack2.suse.cz/T/</Note>
    </Notes>
    <CVE>CVE-2021-47114</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed

We got follow bug_on when run fsstress with injecting IO fault:
[130747.323114] kernel BUG at fs/ext4/extents_status.c:762!
[130747.323117] Internal error: Oops - BUG: 0 [#1] SMP
......
[130747.334329] Call trace:
[130747.334553]  ext4_es_cache_extent+0x150/0x168 [ext4]
[130747.334975]  ext4_cache_extents+0x64/0xe8 [ext4]
[130747.335368]  ext4_find_extent+0x300/0x330 [ext4]
[130747.335759]  ext4_ext_map_blocks+0x74/0x1178 [ext4]
[130747.336179]  ext4_map_blocks+0x2f4/0x5f0 [ext4]
[130747.336567]  ext4_mpage_readpages+0x4a8/0x7a8 [ext4]
[130747.336995]  ext4_readpage+0x54/0x100 [ext4]
[130747.337359]  generic_file_buffered_read+0x410/0xae8
[130747.337767]  generic_file_read_iter+0x114/0x190
[130747.338152]  ext4_file_read_iter+0x5c/0x140 [ext4]
[130747.338556]  __vfs_read+0x11c/0x188
[130747.338851]  vfs_read+0x94/0x150
[130747.339110]  ksys_read+0x74/0xf0

This patch's modification is according to Jan Kara's suggestion in:
https://patchwork.ozlabs.org/project/linux-ext4/patch/20210428085158.3728201-1-yebin10@huawei.com/
"I see. Now I understand your patch. Honestly, seeing how fragile is trying
to fix extent tree after split has failed in the middle, I would probably
go even further and make sure we fix the tree properly in case of ENOSPC
and EDQUOT (those are easily user triggerable).  Anything else indicates a
HW problem or fs corruption so I'd rather leave the extent tree as is and
don't try to fix it (which also means we will not create overlapping
extents)."</Note>
    </Notes>
    <CVE>CVE-2021-47117</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pid: take a reference when initializing `cad_pid`

During boot, kernel_init_freeable() initializes `cad_pid` to the init
task's struct pid.  Later on, we may change `cad_pid` via a sysctl, and
when this happens proc_do_cad_pid() will increment the refcount on the
new pid via get_pid(), and will decrement the refcount on the old pid
via put_pid().  As we never called get_pid() when we initialized
`cad_pid`, we decrement a reference we never incremented, can therefore
free the init task's struct pid early.  As there can be dangling
references to the struct pid, we can later encounter a use-after-free
(e.g.  when delivering signals).

This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to
have been around since the conversion of `cad_pid` to struct pid in
commit 9ec52099e4b8 ("[PATCH] replace cad_pid by a struct pid") from the
pre-KASAN stone age of v2.6.19.

Fix this by getting a reference to the init task's struct pid when we
assign it to `cad_pid`.

Full KASAN splat below.

   ==================================================================
   BUG: KASAN: use-after-free in ns_of_pid include/linux/pid.h:153 [inline]
   BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509
   Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273

   CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1
   Hardware name: linux,dummy-virt (DT)
   Call trace:
    ns_of_pid include/linux/pid.h:153 [inline]
    task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509
    do_notify_parent+0x308/0xe60 kernel/signal.c:1950
    exit_notify kernel/exit.c:682 [inline]
    do_exit+0x2334/0x2bd0 kernel/exit.c:845
    do_group_exit+0x108/0x2c8 kernel/exit.c:922
    get_signal+0x4e4/0x2a88 kernel/signal.c:2781
    do_signal arch/arm64/kernel/signal.c:882 [inline]
    do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936
    work_pending+0xc/0x2dc

   Allocated by task 0:
    slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516
    slab_alloc_node mm/slub.c:2907 [inline]
    slab_alloc mm/slub.c:2915 [inline]
    kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920
    alloc_pid+0xdc/0xc00 kernel/pid.c:180
    copy_process+0x2794/0x5e18 kernel/fork.c:2129
    kernel_clone+0x194/0x13c8 kernel/fork.c:2500
    kernel_thread+0xd4/0x110 kernel/fork.c:2552
    rest_init+0x44/0x4a0 init/main.c:687
    arch_call_rest_init+0x1c/0x28
    start_kernel+0x520/0x554 init/main.c:1064
    0x0

   Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline]
    slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600
    slab_free mm/slub.c:3161 [inline]
    kmem_cache_free+0x224/0x8e0 mm/slub.c:3177
    put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114
    put_pid+0x30/0x48 kernel/pid.c:109
    proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401
    proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591
    proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617
    call_write_iter include/linux/fs.h:1977 [inline]
    new_sync_write+0x3ac/0x510 fs/read_write.c:518
    vfs_write fs/read_write.c:605 [inline]
    vfs_write+0x9c4/0x1018 fs/read_write.c:585
    ksys_write+0x124/0x240 fs/read_write.c:658
    __do_sys_write fs/read_write.c:670 [inline]
    __se_sys_write fs/read_write.c:667 [inline]
    __arm64_sys_write+0x78/0xb0 fs/read_write.c:667
    __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
    invoke_syscall arch/arm64/kernel/syscall.c:49 [inline]
    el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129
    do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168
    el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416
    el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432
    el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701

   The buggy address belongs to the object at ffff23794dda0000
    which belongs to the cache pid of size 224
   The buggy address is located 4 bytes inside of
    224-byte region [ff
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47118</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: fix memory leak in ext4_fill_super

Buffer head references must be released before calling kill_bdev();
otherwise the buffer head (and its page referenced by b_data) will not
be freed by kill_bdev, and subsequently that bh will be leaked.

If blocksizes differ, sb_set_blocksize() will kill current buffers and
page cache by using kill_bdev(). And then super block will be reread
again but using correct blocksize this time. sb_set_blocksize() didn't
fully free superblock page and buffer head, and being busy, they were
not freed and instead leaked.

This can easily be reproduced by calling an infinite loop of:

  systemctl start &lt;ext4_on_lvm&gt;.mount, and
  systemctl stop &lt;ext4_on_lvm&gt;.mount

... since systemd creates a cgroup for each slice which it mounts, and
the bh leak get amplified by a dying memory cgroup that also never
gets freed, and memory consumption is much more easily noticed.</Note>
    </Notes>
    <CVE>CVE-2021-47119</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/tls: Fix use-after-free after the TLS device goes down and up

When a netdev with active TLS offload goes down, tls_device_down is
called to stop the offload and tear down the TLS context. However, the
socket stays alive, and it still points to the TLS context, which is now
deallocated. If a netdev goes up, while the connection is still active,
and the data flow resumes after a number of TCP retransmissions, it will
lead to a use-after-free of the TLS context.

This commit addresses this bug by keeping the context alive until its
normal destruction, and implements the necessary fallbacks, so that the
connection can resume in software (non-offloaded) kTLS mode.

On the TX side tls_sw_fallback is used to encrypt all packets. The RX
side already has all the necessary fallbacks, because receiving
non-decrypted packets is supported. The thing needed on the RX side is
to block resync requests, which are normally produced after receiving
non-decrypted packets.

The necessary synchronization is implemented for a graceful teardown:
first the fallbacks are deployed, then the driver resources are released
(it used to be possible to have a tls_dev_resync after tls_dev_del).

A new flag called TLS_RX_DEV_DEGRADED is added to indicate the fallback
mode. It's used to skip the RX resync logic completely, as it becomes
useless, and some objects may be released (for example, resync_async,
which is allocated and freed by the driver).</Note>
    </Notes>
    <CVE>CVE-2021-47131</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cxgb4: avoid accessing registers when clearing filters

Hardware register having the server TID base can contain
invalid values when adapter is in bad state (for example,
due to AER fatal error). Reading these invalid values in the
register can lead to out-of-bound memory access. So, fix
by using the saved server TID base when clearing filters.</Note>
    </Notes>
    <CVE>CVE-2021-47138</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Add NULL pointer checks when freeing irqs.

When freeing notification blocks, we index priv-&gt;msix_vectors.
If we failed to allocate priv-&gt;msix_vectors (see abort_with_msix_vectors)
this could lead to a NULL pointer dereference if the driver is unloaded.</Note>
    </Notes>
    <CVE>CVE-2021-47141</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 a use-after-free

looks like we forget to set ttm-&gt;sg to NULL.
Hit panic below

[ 1235.844104] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b7b4b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI
[ 1235.989074] Call Trace:
[ 1235.991751]  sg_free_table+0x17/0x20
[ 1235.995667]  amdgpu_ttm_backend_unbind.cold+0x4d/0xf7 [amdgpu]
[ 1236.002288]  amdgpu_ttm_backend_destroy+0x29/0x130 [amdgpu]
[ 1236.008464]  ttm_tt_destroy+0x1e/0x30 [ttm]
[ 1236.013066]  ttm_bo_cleanup_memtype_use+0x51/0xa0 [ttm]
[ 1236.018783]  ttm_bo_release+0x262/0xa50 [ttm]
[ 1236.023547]  ttm_bo_put+0x82/0xd0 [ttm]
[ 1236.027766]  amdgpu_bo_unref+0x26/0x50 [amdgpu]
[ 1236.032809]  amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7aa/0xd90 [amdgpu]
[ 1236.040400]  kfd_ioctl_alloc_memory_of_gpu+0xe2/0x330 [amdgpu]
[ 1236.046912]  kfd_ioctl+0x463/0x690 [amdgpu]</Note>
    </Notes>
    <CVE>CVE-2021-47142</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: remove device from smcd_dev_list after failed device_add()

If the device_add() for a smcd_dev fails, there's no cleanup step that
rolls back the earlier list_add(). The device subsequently gets freed,
and we end up with a corrupted list.

Add some error handling that removes the device from the list.</Note>
    </Notes>
    <CVE>CVE-2021-47143</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: do not BUG_ON in link_to_fixup_dir

While doing error injection testing I got the following panic

  kernel BUG at fs/btrfs/tree-log.c:1862!
  invalid opcode: 0000 [#1] SMP NOPTI
  CPU: 1 PID: 7836 Comm: mount Not tainted 5.13.0-rc1+ #305
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
  RIP: 0010:link_to_fixup_dir+0xd5/0xe0
  RSP: 0018:ffffb5800180fa30 EFLAGS: 00010216
  RAX: fffffffffffffffb RBX: 00000000fffffffb RCX: ffff8f595287faf0
  RDX: ffffb5800180fa37 RSI: ffff8f5954978800 RDI: 0000000000000000
  RBP: ffff8f5953af9450 R08: 0000000000000019 R09: 0000000000000001
  R10: 000151f408682970 R11: 0000000120021001 R12: ffff8f5954978800
  R13: ffff8f595287faf0 R14: ffff8f5953c77dd0 R15: 0000000000000065
  FS:  00007fc5284c8c40(0000) GS:ffff8f59bbd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007fc5287f47c0 CR3: 000000011275e002 CR4: 0000000000370ee0
  Call Trace:
   replay_one_buffer+0x409/0x470
   ? btree_read_extent_buffer_pages+0xd0/0x110
   walk_up_log_tree+0x157/0x1e0
   walk_log_tree+0xa6/0x1d0
   btrfs_recover_log_trees+0x1da/0x360
   ? replay_one_extent+0x7b0/0x7b0
   open_ctree+0x1486/0x1720
   btrfs_mount_root.cold+0x12/0xea
   ? __kmalloc_track_caller+0x12f/0x240
   legacy_get_tree+0x24/0x40
   vfs_get_tree+0x22/0xb0
   vfs_kern_mount.part.0+0x71/0xb0
   btrfs_mount+0x10d/0x380
   ? vfs_parse_fs_string+0x4d/0x90
   legacy_get_tree+0x24/0x40
   vfs_get_tree+0x22/0xb0
   path_mount+0x433/0xa10
   __x64_sys_mount+0xe3/0x120
   do_syscall_64+0x3d/0x80
   entry_SYSCALL_64_after_hwframe+0x44/0xae

We can get -EIO or any number of legitimate errors from
btrfs_search_slot(), panicing here is not the appropriate response.  The
error path for this code handles errors properly, simply return the
error.</Note>
    </Notes>
    <CVE>CVE-2021-47145</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mld: fix panic in mld_newpack()

mld_newpack() doesn't allow to allocate high order page,
only order-0 allocation is allowed.
If headroom size is too large, a kernel panic could occur in skb_put().

Test commands:
    ip netns del A
    ip netns del B
    ip netns add A
    ip netns add B
    ip link add veth0 type veth peer name veth1
    ip link set veth0 netns A
    ip link set veth1 netns B

    ip netns exec A ip link set lo up
    ip netns exec A ip link set veth0 up
    ip netns exec A ip -6 a a 2001:db8:0::1/64 dev veth0
    ip netns exec B ip link set lo up
    ip netns exec B ip link set veth1 up
    ip netns exec B ip -6 a a 2001:db8:0::2/64 dev veth1
    for i in {1..99}
    do
        let A=$i-1
        ip netns exec A ip link add ip6gre$i type ip6gre \
	local 2001:db8:$A::1 remote 2001:db8:$A::2 encaplimit 100
        ip netns exec A ip -6 a a 2001:db8:$i::1/64 dev ip6gre$i
        ip netns exec A ip link set ip6gre$i up

        ip netns exec B ip link add ip6gre$i type ip6gre \
	local 2001:db8:$A::2 remote 2001:db8:$A::1 encaplimit 100
        ip netns exec B ip -6 a a 2001:db8:$i::2/64 dev ip6gre$i
        ip netns exec B ip link set ip6gre$i up
    done

Splat looks like:
kernel BUG at net/core/skbuff.c:110!
invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.12.0+ #891
Workqueue: ipv6_addrconf addrconf_dad_work
RIP: 0010:skb_panic+0x15d/0x15f
Code: 92 fe 4c 8b 4c 24 10 53 8b 4d 70 45 89 e0 48 c7 c7 00 ae 79 83
41 57 41 56 41 55 48 8b 54 24 a6 26 f9 ff &lt;0f&gt; 0b 48 8b 6c 24 20 89
34 24 e8 4a 4e 92 fe 8b 34 24 48 c7 c1 20
RSP: 0018:ffff88810091f820 EFLAGS: 00010282
RAX: 0000000000000089 RBX: ffff8881086e9000 RCX: 0000000000000000
RDX: 0000000000000089 RSI: 0000000000000008 RDI: ffffed1020123efb
RBP: ffff888005f6eac0 R08: ffffed1022fc0031 R09: ffffed1022fc0031
R10: ffff888117e00187 R11: ffffed1022fc0030 R12: 0000000000000028
R13: ffff888008284eb0 R14: 0000000000000ed8 R15: 0000000000000ec0
FS:  0000000000000000(0000) GS:ffff888117c00000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8b801c5640 CR3: 0000000033c2c006 CR4: 00000000003706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600
 ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600
 skb_put.cold.104+0x22/0x22
 ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600
 ? rcu_read_lock_sched_held+0x91/0xc0
 mld_newpack+0x398/0x8f0
 ? ip6_mc_hdr.isra.26.constprop.46+0x600/0x600
 ? lock_contended+0xc40/0xc40
 add_grhead.isra.33+0x280/0x380
 add_grec+0x5ca/0xff0
 ? mld_sendpack+0xf40/0xf40
 ? lock_downgrade+0x690/0x690
 mld_send_initial_cr.part.34+0xb9/0x180
 ipv6_mc_dad_complete+0x15d/0x1b0
 addrconf_dad_completed+0x8d2/0xbb0
 ? lock_downgrade+0x690/0x690
 ? addrconf_rs_timer+0x660/0x660
 ? addrconf_dad_work+0x73c/0x10e0
 addrconf_dad_work+0x73c/0x10e0

Allowing high order page allocation could fix this problem.</Note>
    </Notes>
    <CVE>CVE-2021-47146</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fujitsu: fix potential null-ptr-deref

In fmvj18x_get_hwinfo(), if ioremap fails there will be NULL pointer
deref. To fix this, check the return value of ioremap and return -1
to the caller in case of failure.</Note>
    </Notes>
    <CVE>CVE-2021-47149</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: fec: fix the potential memory leak in fec_enet_init()

If the memory allocated for cbd_base is failed, it should
free the memory allocated for the queues, otherwise it causes
memory leak.

And if the memory allocated for the queues is failed, it can
return error directly.</Note>
    </Notes>
    <CVE>CVE-2021-47150</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: i801: Don't generate an interrupt on bus reset

Now that the i2c-i801 driver supports interrupts, setting the KILL bit
in a attempt to recover from a timed out transaction triggers an
interrupt. Unfortunately, the interrupt handler (i801_isr) is not
prepared for this situation and will try to process the interrupt as
if it was signaling the end of a successful transaction. In the case
of a block transaction, this can result in an out-of-range memory
access.

This condition was reproduced several times by syzbot:
https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e
https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e
https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e
https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb
https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a
https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79

So disable interrupts while trying to reset the bus. Interrupts will
be enabled again for the following transaction.</Note>
    </Notes>
    <CVE>CVE-2021-47153</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

spi: spi-fsl-dspi: Fix a resource leak in an error handling path

'dspi_request_dma()' should be undone by a 'dspi_release_dma()' call in the
error handling path of the probe function, as already done in the remove
function</Note>
    </Notes>
    <CVE>CVE-2021-47161</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/meson: fix shutdown crash when component not probed

When main component is not probed, by example when the dw-hdmi module is
not loaded yet or in probe defer, the following crash appears on shutdown:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038
...
pc : meson_drv_shutdown+0x24/0x50
lr : platform_drv_shutdown+0x20/0x30
...
Call trace:
meson_drv_shutdown+0x24/0x50
platform_drv_shutdown+0x20/0x30
device_shutdown+0x158/0x360
kernel_restart_prepare+0x38/0x48
kernel_restart+0x18/0x68
__do_sys_reboot+0x224/0x250
__arm64_sys_reboot+0x24/0x30
...

Simply check if the priv struct has been allocated before using it.</Note>
    </Notes>
    <CVE>CVE-2021-47165</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Don't corrupt the value of pg_bytes_written in nfs_do_recoalesce()

The value of mirror-&gt;pg_bytes_written should only be updated after a
successful attempt to flush out the requests on the list.</Note>
    </Notes>
    <CVE>CVE-2021-47166</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NFS: Fix an Oopsable condition in __nfs_pageio_add_request()

Ensure that nfs_pageio_error_cleanup() resets the mirror array contents,
so that the structure reflects the fact that it is now empty.
Also change the test in nfs_pageio_do_add_request() to be more robust by
checking whether or not the list is empty rather than relying on the
value of pg_count.</Note>
    </Notes>
    <CVE>CVE-2021-47167</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NFS: fix an incorrect limit in filelayout_decode_layout()

The "sizeof(struct nfs_fh)" is two bytes too large and could lead to
memory corruption.  It should be NFS_MAXFHSIZE because that's the size
of the -&gt;data[] buffer.

I reversed the size of the arguments to put the variable on the left.</Note>
    </Notes>
    <CVE>CVE-2021-47168</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rp2: use 'request_firmware' instead of 'request_firmware_nowait'

In 'rp2_probe', the driver registers 'rp2_uart_interrupt' then calls
'rp2_fw_cb' through 'request_firmware_nowait'. In 'rp2_fw_cb', if the
firmware don't exists, function just return without initializing ports
of 'rp2_card'. But now the interrupt handler function has been
registered, and when an interrupt comes, 'rp2_uart_interrupt' may access
those ports then causing NULL pointer dereference or other bugs.

Because the driver does some initialization work in 'rp2_fw_cb', in
order to make the driver ready to handle interrupts, 'request_firmware'
should be used instead of asynchronous 'request_firmware_nowait'.

This report reveals it:

INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-
gc9ba5276e321-prebuilt.qemu.org 04/01/2014
Call Trace:
 &lt;IRQ&gt;
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xec/0x156 lib/dump_stack.c:118
 assign_lock_key kernel/locking/lockdep.c:727 [inline]
 register_lock_class+0x14e5/0x1ba0 kernel/locking/lockdep.c:753
 __lock_acquire+0x187/0x3750 kernel/locking/lockdep.c:3303
 lock_acquire+0x124/0x340 kernel/locking/lockdep.c:3907
 __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
 _raw_spin_lock+0x32/0x50 kernel/locking/spinlock.c:144
 spin_lock include/linux/spinlock.h:329 [inline]
 rp2_ch_interrupt drivers/tty/serial/rp2.c:466 [inline]
 rp2_asic_interrupt.isra.9+0x15d/0x990 drivers/tty/serial/rp2.c:493
 rp2_uart_interrupt+0x49/0xe0 drivers/tty/serial/rp2.c:504
 __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149
 handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189
 handle_irq_event+0xac/0x140 kernel/irq/handle.c:206
 handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725
 generic_handle_irq_desc include/linux/irqdesc.h:155 [inline]
 handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87
 do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247
 common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670
 &lt;/IRQ&gt;
RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61
Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 c2 2f 8c 48 89 e5 e8 fb 31 e7 f8
8b 05 75 af 8d 03 85 c0 7e 07 0f 00 2d 8a 61 65 00 fb f4 &lt;5d&gt; c3 90 90 90
90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41
RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde
RAX: 0000000000000000 RBX: ffffffff8bde7e48 RCX: ffffffff88a21285
RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2fc200
RBP: ffff88806b71fcc8 R08: fffffbfff185f840 R09: fffffbfff185f840
R10: 0000000000000001 R11: fffffbfff185f840 R12: 0000000000000002
R13: ffffffff8bea18a0 R14: 0000000000000000 R15: 0000000000000000
 arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
 default_idle+0x6f/0x360 arch/x86/kernel/process.c:557
 arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548
 default_idle_call+0x3b/0x60 kernel/sched/idle.c:93
 cpuidle_idle_call kernel/sched/idle.c:153 [inline]
 do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263
 cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369
 start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271
 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243
BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
PGD 8000000056d27067 P4D 8000000056d27067 PUD 56d28067 PMD 0
Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-
gc9ba5276e321-prebuilt.qemu.org 04/01/2014
RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline]
RIP: 0010:rp2_ch_interrupt drivers/tty/serial/rp2.c:472 [inline]
RIP: 0010:rp2_asic_interrupt.isra.9+0x181/0x990 drivers/tty/serial/rp2.c:
493
Co
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47169</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix memory leak in smsc75xx_bind

Syzbot reported memory leak in smsc75xx_bind().
The problem was is non-freed memory in case of
errors after memory allocation.

backtrace:
  [&lt;ffffffff84245b62&gt;] kmalloc include/linux/slab.h:556 [inline]
  [&lt;ffffffff84245b62&gt;] kzalloc include/linux/slab.h:686 [inline]
  [&lt;ffffffff84245b62&gt;] smsc75xx_bind+0x7a/0x334 drivers/net/usb/smsc75xx.c:1460
  [&lt;ffffffff82b5b2e6&gt;] usbnet_probe+0x3b6/0xc30 drivers/net/usb/usbnet.c:1728</Note>
    </Notes>
    <CVE>CVE-2021-47171</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

misc/uss720: fix memory leak in uss720_probe

uss720_probe forgets to decrease the refcount of usbdev in uss720_probe.
Fix this by decreasing the refcount of usbdev by usb_put_dev.

BUG: memory leak
unreferenced object 0xffff888101113800 (size 2048):
  comm "kworker/0:1", pid 7, jiffies 4294956777 (age 28.870s)
  hex dump (first 32 bytes):
    ff ff ff ff 31 00 00 00 00 00 00 00 00 00 00 00  ....1...........
    00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00  ................
  backtrace:
    [&lt;ffffffff82b8e822&gt;] kmalloc include/linux/slab.h:554 [inline]
    [&lt;ffffffff82b8e822&gt;] kzalloc include/linux/slab.h:684 [inline]
    [&lt;ffffffff82b8e822&gt;] usb_alloc_dev+0x32/0x450 drivers/usb/core/usb.c:582
    [&lt;ffffffff82b98441&gt;] hub_port_connect drivers/usb/core/hub.c:5129 [inline]
    [&lt;ffffffff82b98441&gt;] hub_port_connect_change drivers/usb/core/hub.c:5363 [inline]
    [&lt;ffffffff82b98441&gt;] port_event drivers/usb/core/hub.c:5509 [inline]
    [&lt;ffffffff82b98441&gt;] hub_event+0x1171/0x20c0 drivers/usb/core/hub.c:5591
    [&lt;ffffffff81259229&gt;] process_one_work+0x2c9/0x600 kernel/workqueue.c:2275
    [&lt;ffffffff81259b19&gt;] worker_thread+0x59/0x5d0 kernel/workqueue.c:2421
    [&lt;ffffffff81261228&gt;] kthread+0x178/0x1b0 kernel/kthread.c:292
    [&lt;ffffffff8100227f&gt;] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294</Note>
    </Notes>
    <CVE>CVE-2021-47173</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 sysfs leak in alloc_iommu()

iommu_device_sysfs_add() is called before, so is has to be cleaned on subsequent
errors.</Note>
    </Notes>
    <CVE>CVE-2021-47177</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NFSv4: Fix a NULL pointer dereference in pnfs_mark_matching_lsegs_return()

Commit de144ff4234f changes _pnfs_return_layout() to call
pnfs_mark_matching_lsegs_return() passing NULL as the struct
pnfs_layout_range argument. Unfortunately,
pnfs_mark_matching_lsegs_return() doesn't check if we have a value here
before dereferencing it, causing an oops.

I'm able to hit this crash consistently when running connectathon basic
tests on NFS v4.1/v4.2 against Ontap.</Note>
    </Notes>
    <CVE>CVE-2021-47179</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 memory leak in nci_allocate_device

nfcmrvl_disconnect fails to free the hci_dev field in struct nci_dev.
Fix this by freeing hci_dev in nci_free_device.

BUG: memory leak
unreferenced object 0xffff888111ea6800 (size 1024):
  comm "kworker/1:0", pid 19, jiffies 4294942308 (age 13.580s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 60 fd 0c 81 88 ff ff  .........`......
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;000000004bc25d43&gt;] kmalloc include/linux/slab.h:552 [inline]
    [&lt;000000004bc25d43&gt;] kzalloc include/linux/slab.h:682 [inline]
    [&lt;000000004bc25d43&gt;] nci_hci_allocate+0x21/0xd0 net/nfc/nci/hci.c:784
    [&lt;00000000c59cff92&gt;] nci_allocate_device net/nfc/nci/core.c:1170 [inline]
    [&lt;00000000c59cff92&gt;] nci_allocate_device+0x10b/0x160 net/nfc/nci/core.c:1132
    [&lt;00000000006e0a8e&gt;] nfcmrvl_nci_register_dev+0x10a/0x1c0 drivers/nfc/nfcmrvl/main.c:153
    [&lt;000000004da1b57e&gt;] nfcmrvl_probe+0x223/0x290 drivers/nfc/nfcmrvl/usb.c:345
    [&lt;00000000d506aed9&gt;] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
    [&lt;00000000bc632c92&gt;] really_probe+0x159/0x4a0 drivers/base/dd.c:554
    [&lt;00000000f5009125&gt;] driver_probe_device+0x84/0x100 drivers/base/dd.c:740
    [&lt;000000000ce658ca&gt;] __device_attach_driver+0xee/0x110 drivers/base/dd.c:846
    [&lt;000000007067d05f&gt;] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431
    [&lt;00000000f8e13372&gt;] __device_attach+0x122/0x250 drivers/base/dd.c:914
    [&lt;000000009cf68860&gt;] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491
    [&lt;00000000359c965a&gt;] device_add+0x5be/0xc30 drivers/base/core.c:3109
    [&lt;00000000086e4bd3&gt;] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2164
    [&lt;00000000ca036872&gt;] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238
    [&lt;00000000d40d36f6&gt;] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293
    [&lt;00000000bc632c92&gt;] really_probe+0x159/0x4a0 drivers/base/dd.c:554</Note>
    </Notes>
    <CVE>CVE-2021-47180</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: musb: tusb6010: check return value after calling platform_get_resource()

It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.</Note>
    </Notes>
    <CVE>CVE-2021-47181</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: core: Fix scsi_mode_sense() buffer length handling

Several problems exist with scsi_mode_sense() buffer length handling:

 1) The allocation length field of the MODE SENSE(10) command is 16-bits,
    occupying bytes 7 and 8 of the CDB. With this command, access to mode
    pages larger than 255 bytes is thus possible. However, the CDB
    allocation length field is set by assigning len to byte 8 only, thus
    truncating buffer length larger than 255.

 2) If scsi_mode_sense() is called with len smaller than 8 with
    sdev-&gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length
    is increased to 8 and 4 respectively, and the buffer is zero filled
    with these increased values, thus corrupting the memory following the
    buffer.

Fix these 2 problems by using put_unaligned_be16() to set the allocation
length field of MODE SENSE(10) CDB and by returning an error when len is
too small.

Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
even if the device driver did not set sdev-&gt;use_10_for_ms. In case of
invalid opcode error for MODE SENSE(10), access to mode pages larger than
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
bytes.

While at it, also fix the folowing:

 * Use get_unaligned_be16() to retrieve the mode data length and block
   descriptor length fields of the mode sense reply header instead of using
   an open coded calculation.

 * Fix the kdoc dbd argument explanation: the DBD bit stands for Disable
   Block Descriptor, which is the opposite of what the dbd argument
   description was.</Note>
    </Notes>
    <CVE>CVE-2021-47182</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Fix link down processing to address NULL pointer dereference

If an FC link down transition while PLOGIs are outstanding to fabric well
known addresses, outstanding ABTS requests may result in a NULL pointer
dereference. Driver unload requests may hang with repeated "2878" log
messages.

The Link down processing results in ABTS requests for outstanding ELS
requests. The Abort WQEs are sent for the ELSs before the driver had set
the link state to down. Thus the driver is sending the Abort with the
expectation that an ABTS will be sent on the wire. The Abort request is
stalled waiting for the link to come up. In some conditions the driver may
auto-complete the ELSs thus if the link does come up, the Abort completions
may reference an invalid structure.

Fix by ensuring that Abort set the flag to avoid link traffic if issued due
to conditions where the link failed.</Note>
    </Notes>
    <CVE>CVE-2021-47183</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i40e: Fix NULL ptr dereference on VSI filter sync

Remove the reason of null pointer dereference in sync VSI filters.
Added new I40E_VSI_RELEASING flag to signalize deleting and releasing
of VSI resources to sync this thread with sync filters subtask.
Without this patch it is possible to start update the VSI filter list
after VSI is removed, that's causing a kernel oops.</Note>
    </Notes>
    <CVE>CVE-2021-47184</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc

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

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

In the testcase pty04, The first process call the write syscall to send
data to the pty master. At the same time, the workqueue will do the
flush_to_ldisc to pop data in a loop until there is no more data left.
When the sender and workqueue running in different core, the sender sends
data fastly in full time which will result in workqueue doing work in loop
for a long time and occuring softlockup in flush_to_ldisc with kernel
configured without preempt. So I add need_resched check and cond_resched
in the flush_to_ldisc loop to avoid it.</Note>
    </Notes>
    <CVE>CVE-2021-47185</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: core: Improve SCSI abort handling

The following has been observed on a test setup:

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

That warning is triggered by the following statement:

	WARN_ON(lrbp-&gt;cmd);

Fix this warning by clearing lrbp-&gt;cmd from the abort handler.</Note>
    </Notes>
    <CVE>CVE-2021-47188</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 memory ordering between normal and ordered work functions

Ordered work functions aren't guaranteed to be handled by the same thread
which executed the normal work functions. The only way execution between
normal/ordered functions is synchronized is via the WORK_DONE_BIT,
unfortunately the used bitops don't guarantee any ordering whatsoever.

This manifested as seemingly inexplicable crashes on ARM64, where
async_chunk::inode is seen as non-null in async_cow_submit which causes
submit_compressed_extents to be called and crash occurs because
async_chunk::inode suddenly became NULL. The call trace was similar to:

    pc : submit_compressed_extents+0x38/0x3d0
    lr : async_cow_submit+0x50/0xd0
    sp : ffff800015d4bc20

    &lt;registers omitted for brevity&gt;

    Call trace:
     submit_compressed_extents+0x38/0x3d0
     async_cow_submit+0x50/0xd0
     run_ordered_work+0xc8/0x280
     btrfs_work_helper+0x98/0x250
     process_one_work+0x1f0/0x4ac
     worker_thread+0x188/0x504
     kthread+0x110/0x114
     ret_from_fork+0x10/0x18

Fix this by adding respective barrier calls which ensure that all
accesses preceding setting of WORK_DONE_BIT are strictly ordered before
setting the flag. At the same time add a read barrier after reading of
WORK_DONE_BIT in run_ordered_work which ensures all subsequent loads
would be strictly ordered after reading the bit. This in turn ensures
are all accesses before WORK_DONE_BIT are going to be strictly ordered
before any access that can occur in ordered_func.</Note>
    </Notes>
    <CVE>CVE-2021-47189</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: pm80xx: Fix memory leak during rmmod

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

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

scsi: lpfc: Fix use-after-free in lpfc_unreg_rpi() routine

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

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

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

Fix by clearing the NLP_REG_LOGIN_SEND nlp_flag in
lpfc_mbx_cmpl_fc_reg_login().</Note>
    </Notes>
    <CVE>CVE-2021-47198</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iavf: free q_vectors before queues in iavf_disable_vf

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

thermal: Fix NULL pointer dereferences in of_thermal_ functions

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

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

While at it, fix the possible NULL pointer dereference in other
functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(),
of_thermal_get_trend().</Note>
    </Notes>
    <CVE>CVE-2021-47202</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq()

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

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

Fix by clearing the fail_msg string after adding a job to the completions
list. This stops the subsequent jobs from being added to the completions
list unless they had an appropriate failure.</Note>
    </Notes>
    <CVE>CVE-2021-47203</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: dpaa2-eth: fix use-after-free in dpaa2_eth_remove

Access to netdev after free_netdev() will cause use-after-free bug.
Move debug log before free_netdev() call to avoid it.</Note>
    </Notes>
    <CVE>CVE-2021-47204</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: sunxi-ng: Unregister clocks/resets when unbinding

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

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

Early OF clock providers are never unregistered, and limited error
handling is possible, so they are mostly unchanged. The error reporting
is made more consistent by moving the message inside of_sunxi_ccu_probe.</Note>
    </Notes>
    <CVE>CVE-2021-47205</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: host: ohci-tmio: check return value after calling platform_get_resource()

It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.</Note>
    </Notes>
    <CVE>CVE-2021-47206</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: gus: fix null pointer dereference on pointer block

The pointer block return from snd_gf1_dma_next_block could be
null, so there is a potential null pointer dereference issue.
Fix this by adding a null check before dereference.</Note>
    </Notes>
    <CVE>CVE-2021-47207</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: fix null pointer dereference on pointer cs_desc

The pointer cs_desc return from snd_usb_find_clock_source could
be null, so there is a potential null pointer dereference issue.
Fix this by adding a null check before dereference.</Note>
    </Notes>
    <CVE>CVE-2021-47211</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: advansys: Fix kernel pointer leak

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

Change %lx to %p to print the hashed pointer.</Note>
    </Notes>
    <CVE>CVE-2021-47216</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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:

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

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

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

Trying to start a new PIO transfer by writing value 0 in PIO_START register
when previous transfer has not yet completed (which is indicated by value 1
in PIO_START) causes an External Abort on CPU, which results in kernel
panic:

    SError Interrupt on CPU0, code 0xbf000002 -- SError
    Kernel panic - not syncing: Asynchronous SError Interrupt

To prevent kernel panic, it is required to reject a new PIO transfer when
previous one has not finished yet.

If previous PIO transfer is not finished yet, the kernel may issue a new
PIO request only if the previous PIO transfer timed out.

In the past the root cause of this issue was incorrectly identified (as it
often happens during link retraining or after link down event) and special
hack was implemented in Trusted Firmware to catch all SError events in EL3,
to ignore errors with code 0xbf000002 and not forwarding any other errors
to kernel and instead throw panic from EL3 Trusted Firmware handler.

Links to discussion and patches about this issue:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50
https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/
https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541

But the real cause was the fact that during link retraining or after link
down event the PIO transfer may take longer time, up to the 1.44s until it
times out. This increased probability that a new PIO transfer would be
issued by kernel while previous one has not finished yet.

After applying this change into the kernel, it is possible to revert the
mentioned TF-A hack and SError events do not have to be caught in TF-A EL3.</Note>
    </Notes>
    <CVE>CVE-2021-47229</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

can: mcba_usb: fix memory leak in mcba_usb

Syzbot reported memory leak in SocketCAN driver for Microchip CAN BUS
Analyzer Tool. The problem was in unfreed usb_coherent.

In mcba_usb_start() 20 coherent buffers are allocated and there is
nothing, that frees them:

1) In callback function the urb is resubmitted and that's all
2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER
   is not set (see mcba_usb_start) and this flag cannot be used with
   coherent buffers.

Fail log:
| [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected
| [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem)

So, all allocated buffers should be freed with usb_free_coherent()
explicitly

NOTE:
The same pattern for allocating and freeing coherent buffers
is used in drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c</Note>
    </Notes>
    <CVE>CVE-2021-47231</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ethernet: fix potential use-after-free in ec_bhf_remove

static void ec_bhf_remove(struct pci_dev *dev)
{
...
	struct ec_bhf_priv *priv = netdev_priv(net_dev);

	unregister_netdev(net_dev);
	free_netdev(net_dev);

	pci_iounmap(dev, priv-&gt;dma_io);
	pci_iounmap(dev, priv-&gt;io);
...
}

priv is netdev private data, but it is used
after free_netdev(). It can cause use-after-free when accessing priv
pointer. So, fix it by moving free_netdev() after pci_iounmap()
calls.</Note>
    </Notes>
    <CVE>CVE-2021-47235</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: cdc_eem: fix tx fixup skb leak

when usbnet transmit a skb, eem fixup it in eem_tx_fixup(),
if skb_copy_expand() failed, it return NULL,
usbnet_start_xmit() will have no chance to free original skb.

fix it by free orginal skb in eem_tx_fixup() first,
then check skb clone status, if failed, return NULL to usbnet.</Note>
    </Notes>
    <CVE>CVE-2021-47236</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hamradio: fix memory leak in mkiss_close

My local syzbot instance hit memory leak in
mkiss_open()[1]. The problem was in missing
free_netdev() in mkiss_close().

In mkiss_open() netdevice is allocated and then
registered, but in mkiss_close() netdevice was
only unregistered, but not freed.

Fail log:

BUG: memory leak
unreferenced object 0xffff8880281ba000 (size 4096):
  comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)
  hex dump (first 32 bytes):
    61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00  ax0.............
    00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00  .'.*............
  backtrace:
    [&lt;ffffffff81a27201&gt;] kvmalloc_node+0x61/0xf0
    [&lt;ffffffff8706e7e8&gt;] alloc_netdev_mqs+0x98/0xe80
    [&lt;ffffffff84e64192&gt;] mkiss_open+0xb2/0x6f0 [1]
    [&lt;ffffffff842355db&gt;] tty_ldisc_open+0x9b/0x110
    [&lt;ffffffff84236488&gt;] tty_set_ldisc+0x2e8/0x670
    [&lt;ffffffff8421f7f3&gt;] tty_ioctl+0xda3/0x1440
    [&lt;ffffffff81c9f273&gt;] __x64_sys_ioctl+0x193/0x200
    [&lt;ffffffff8911263a&gt;] do_syscall_64+0x3a/0xb0
    [&lt;ffffffff89200068&gt;] entry_SYSCALL_64_after_hwframe+0x44/0xae

BUG: memory leak
unreferenced object 0xffff8880141a9a00 (size 96):
  comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)
  hex dump (first 32 bytes):
    e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff  ...(.......(....
    98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00  .....@..........
  backtrace:
    [&lt;ffffffff8709f68b&gt;] __hw_addr_create_ex+0x5b/0x310
    [&lt;ffffffff8709fb38&gt;] __hw_addr_add_ex+0x1f8/0x2b0
    [&lt;ffffffff870a0c7b&gt;] dev_addr_init+0x10b/0x1f0
    [&lt;ffffffff8706e88b&gt;] alloc_netdev_mqs+0x13b/0xe80
    [&lt;ffffffff84e64192&gt;] mkiss_open+0xb2/0x6f0 [1]
    [&lt;ffffffff842355db&gt;] tty_ldisc_open+0x9b/0x110
    [&lt;ffffffff84236488&gt;] tty_set_ldisc+0x2e8/0x670
    [&lt;ffffffff8421f7f3&gt;] tty_ioctl+0xda3/0x1440
    [&lt;ffffffff81c9f273&gt;] __x64_sys_ioctl+0x193/0x200
    [&lt;ffffffff8911263a&gt;] do_syscall_64+0x3a/0xb0
    [&lt;ffffffff89200068&gt;] entry_SYSCALL_64_after_hwframe+0x44/0xae

BUG: memory leak
unreferenced object 0xffff8880219bfc00 (size 512):
  comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)
  hex dump (first 32 bytes):
    00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ff  ...(............
    80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff81a27201&gt;] kvmalloc_node+0x61/0xf0
    [&lt;ffffffff8706eec7&gt;] alloc_netdev_mqs+0x777/0xe80
    [&lt;ffffffff84e64192&gt;] mkiss_open+0xb2/0x6f0 [1]
    [&lt;ffffffff842355db&gt;] tty_ldisc_open+0x9b/0x110
    [&lt;ffffffff84236488&gt;] tty_set_ldisc+0x2e8/0x670
    [&lt;ffffffff8421f7f3&gt;] tty_ioctl+0xda3/0x1440
    [&lt;ffffffff81c9f273&gt;] __x64_sys_ioctl+0x193/0x200
    [&lt;ffffffff8911263a&gt;] do_syscall_64+0x3a/0xb0
    [&lt;ffffffff89200068&gt;] entry_SYSCALL_64_after_hwframe+0x44/0xae

BUG: memory leak
unreferenced object 0xffff888029b2b200 (size 256):
  comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff81a27201&gt;] kvmalloc_node+0x61/0xf0
    [&lt;ffffffff8706f062&gt;] alloc_netdev_mqs+0x912/0xe80
    [&lt;ffffffff84e64192&gt;] mkiss_open+0xb2/0x6f0 [1]
    [&lt;ffffffff842355db&gt;] tty_ldisc_open+0x9b/0x110
    [&lt;ffffffff84236488&gt;] tty_set_ldisc+0x2e8/0x670
    [&lt;ffffffff8421f7f3&gt;] tty_ioctl+0xda3/0x1440
    [&lt;ffffffff81c9f273&gt;] __x64_sys_ioctl+0x193/0x200
    [&lt;ffffffff8911263a&gt;] do_syscall_64+0x3a/0xb0
    [&lt;ffffffff89200068&gt;] entry_SYSCALL_64_after_hwframe+0x44/0xae</Note>
    </Notes>
    <CVE>CVE-2021-47237</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ipv4: fix memory leak in ip_mc_add1_src

BUG: memory leak
unreferenced object 0xffff888101bc4c00 (size 32):
  comm "syz-executor527", pid 360, jiffies 4294807421 (age 19.329s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    01 00 00 00 00 00 00 00 ac 14 14 bb 00 00 02 00 ................
  backtrace:
    [&lt;00000000f17c5244&gt;] kmalloc include/linux/slab.h:558 [inline]
    [&lt;00000000f17c5244&gt;] kzalloc include/linux/slab.h:688 [inline]
    [&lt;00000000f17c5244&gt;] ip_mc_add1_src net/ipv4/igmp.c:1971 [inline]
    [&lt;00000000f17c5244&gt;] ip_mc_add_src+0x95f/0xdb0 net/ipv4/igmp.c:2095
    [&lt;000000001cb99709&gt;] ip_mc_source+0x84c/0xea0 net/ipv4/igmp.c:2416
    [&lt;0000000052cf19ed&gt;] do_ip_setsockopt net/ipv4/ip_sockglue.c:1294 [inline]
    [&lt;0000000052cf19ed&gt;] ip_setsockopt+0x114b/0x30c0 net/ipv4/ip_sockglue.c:1423
    [&lt;00000000477edfbc&gt;] raw_setsockopt+0x13d/0x170 net/ipv4/raw.c:857
    [&lt;00000000e75ca9bb&gt;] __sys_setsockopt+0x158/0x270 net/socket.c:2117
    [&lt;00000000bdb993a8&gt;] __do_sys_setsockopt net/socket.c:2128 [inline]
    [&lt;00000000bdb993a8&gt;] __se_sys_setsockopt net/socket.c:2125 [inline]
    [&lt;00000000bdb993a8&gt;] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2125
    [&lt;000000006a1ffdbd&gt;] do_syscall_64+0x40/0x80 arch/x86/entry/common.c:47
    [&lt;00000000b11467c4&gt;] entry_SYSCALL_64_after_hwframe+0x44/0xae

In commit 24803f38a5c0 ("igmp: do not remove igmp souce list info when set
link down"), the ip_mc_clear_src() in ip_mc_destroy_dev() was removed,
because it was also called in igmpv3_clear_delrec().

Rough callgraph:

inetdev_destroy
-&gt; ip_mc_destroy_dev
     -&gt; igmpv3_clear_delrec
        -&gt; ip_mc_clear_src
-&gt; RCU_INIT_POINTER(dev-&gt;ip_ptr, NULL)

However, ip_mc_clear_src() called in igmpv3_clear_delrec() doesn't
release in_dev-&gt;mc_list-&gt;sources. And RCU_INIT_POINTER() assigns the
NULL to dev-&gt;ip_ptr. As a result, in_dev cannot be obtained through
inetdev_by_index() and then in_dev-&gt;mc_list-&gt;sources cannot be released
by ip_mc_del1_src() in the sock_close. Rough call sequence goes like:

sock_close
-&gt; __sock_release
   -&gt; inet_release
      -&gt; ip_mc_drop_socket
         -&gt; inetdev_by_index
         -&gt; ip_mc_leave_src
            -&gt; ip_mc_del_src
               -&gt; ip_mc_del1_src

So we still need to call ip_mc_clear_src() in ip_mc_destroy_dev() to free
in_dev-&gt;mc_list-&gt;sources.</Note>
    </Notes>
    <CVE>CVE-2021-47238</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: synproxy: Fix out of bounds when parsing TCP options

The TCP option parser in synproxy (synproxy_parse_options) could read
one byte out of bounds. When the length is 1, the execution flow gets
into the loop, reads one byte of the opcode, and if the opcode is
neither TCPOPT_EOL nor TCPOPT_NOP, it reads one more byte, which exceeds
the length of 1.

This fix is inspired by commit 9609dad263f8 ("ipv4: tcp_input: fix stack
out of bounds when parsing TCP options.").

v2 changes:

Added an early return when length &lt; 0 to avoid calling
skb_header_pointer with negative length.</Note>
    </Notes>
    <CVE>CVE-2021-47245</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 page reclaim for dead peer hairpin

When adding a hairpin flow, a firmware-side send queue is created for
the peer net device, which claims some host memory pages for its
internal ring buffer. If the peer net device is removed/unbound before
the hairpin flow is deleted, then the send queue is not destroyed which
leads to a stack trace on pci device remove:

[ 748.005230] mlx5_core 0000:08:00.2: wait_func:1094:(pid 12985): MANAGE_PAGES(0x108) timeout. Will cause a leak of a command resource
[ 748.005231] mlx5_core 0000:08:00.2: reclaim_pages:514:(pid 12985): failed reclaiming pages: err -110
[ 748.001835] mlx5_core 0000:08:00.2: mlx5_reclaim_root_pages:653:(pid 12985): failed reclaiming pages (-110) for func id 0x0
[ 748.002171] ------------[ cut here ]------------
[ 748.001177] FW pages counter is 4 after reclaiming all pages
[ 748.001186] WARNING: CPU: 1 PID: 12985 at drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c:685 mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core]                      [  +0.002771] Modules linked in: cls_flower mlx5_ib mlx5_core ptp pps_core act_mirred sch_ingress openvswitch nsh xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay fuse [last unloaded: pps_core]
[ 748.007225] CPU: 1 PID: 12985 Comm: tee Not tainted 5.12.0+ #1
[ 748.001376] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
[ 748.002315] RIP: 0010:mlx5_reclaim_startup_pages+0x34b/0x460 [mlx5_core]
[ 748.001679] Code: 28 00 00 00 0f 85 22 01 00 00 48 81 c4 b0 00 00 00 31 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 c7 c7 40 cc 19 a1 e8 9f 71 0e e2 &lt;0f&gt; 0b e9 30 ff ff ff 48 c7 c7 a0 cc 19 a1 e8 8c 71 0e e2 0f 0b e9
[ 748.003781] RSP: 0018:ffff88815220faf8 EFLAGS: 00010286
[ 748.001149] RAX: 0000000000000000 RBX: ffff8881b4900280 RCX: 0000000000000000
[ 748.001445] RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffffed102a441f51
[ 748.001614] RBP: 00000000000032b9 R08: 0000000000000001 R09: ffffed1054a15ee8
[ 748.001446] R10: ffff8882a50af73b R11: ffffed1054a15ee7 R12: fffffbfff07c1e30
[ 748.001447] R13: dffffc0000000000 R14: ffff8881b492cba8 R15: 0000000000000000
[ 748.001429] FS:  00007f58bd08b580(0000) GS:ffff8882a5080000(0000) knlGS:0000000000000000
[ 748.001695] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 748.001309] CR2: 000055a026351740 CR3: 00000001d3b48006 CR4: 0000000000370ea0
[ 748.001506] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 748.001483] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 748.001654] Call Trace:
[ 748.000576]  ? mlx5_satisfy_startup_pages+0x290/0x290 [mlx5_core]
[ 748.001416]  ? mlx5_cmd_teardown_hca+0xa2/0xd0 [mlx5_core]
[ 748.001354]  ? mlx5_cmd_init_hca+0x280/0x280 [mlx5_core]
[ 748.001203]  mlx5_function_teardown+0x30/0x60 [mlx5_core]
[ 748.001275]  mlx5_uninit_one+0xa7/0xc0 [mlx5_core]
[ 748.001200]  remove_one+0x5f/0xc0 [mlx5_core]
[ 748.001075]  pci_device_remove+0x9f/0x1d0
[ 748.000833]  device_release_driver_internal+0x1e0/0x490
[ 748.001207]  unbind_store+0x19f/0x200
[ 748.000942]  ? sysfs_file_ops+0x170/0x170
[ 748.001000]  kernfs_fop_write_iter+0x2bc/0x450
[ 748.000970]  new_sync_write+0x373/0x610
[ 748.001124]  ? new_sync_read+0x600/0x600
[ 748.001057]  ? lock_acquire+0x4d6/0x700
[ 748.000908]  ? lockdep_hardirqs_on_prepare+0x400/0x400
[ 748.001126]  ? fd_install+0x1c9/0x4d0
[ 748.000951]  vfs_write+0x4d0/0x800
[ 748.000804]  ksys_write+0xf9/0x1d0
[ 748.000868]  ? __x64_sys_read+0xb0/0xb0
[ 748.000811]  ? filp_open+0x50/0x50
[ 748.000919]  ? syscall_enter_from_user_mode+0x1d/0x50
[ 748.001223]  do_syscall_64+0x3f/0x80
[ 748.000892]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 748.00
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47246</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

udp: fix race between close() and udp_abort()

Kaustubh reported and diagnosed a panic in udp_lib_lookup().
The root cause is udp_abort() racing with close(). Both
racing functions acquire the socket lock, but udp{v6}_destroy_sock()
release it before performing destructive actions.

We can't easily extend the socket lock scope to avoid the race,
instead use the SOCK_DEAD flag to prevent udp_abort from doing
any action when the critical race happens.

Diagnosed-and-tested-by: Kaustubh Pandey &lt;kapandey@codeaurora.org&gt;</Note>
    </Notes>
    <CVE>CVE-2021-47248</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rds: fix memory leak in rds_recvmsg

Syzbot reported memory leak in rds. The problem
was in unputted refcount in case of error.

int rds_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,
		int msg_flags)
{
...

	if (!rds_next_incoming(rs, &amp;inc)) {
		...
	}

After this "if" inc refcount incremented and

	if (rds_cmsg_recv(inc, msg, rs)) {
		ret = -EFAULT;
		goto out;
	}
...
out:
	return ret;
}

in case of rds_cmsg_recv() fail the refcount won't be
decremented. And it's easy to see from ftrace log, that
rds_inc_addref() don't have rds_inc_put() pair in
rds_recvmsg() after rds_cmsg_recv()

 1)               |  rds_recvmsg() {
 1)   3.721 us    |    rds_inc_addref();
 1)   3.853 us    |    rds_message_inc_copy_to_user();
 1) + 10.395 us   |    rds_cmsg_recv();
 1) + 34.260 us   |  }</Note>
    </Notes>
    <CVE>CVE-2021-47249</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ipv4: fix memory leak in netlbl_cipsov4_add_std

Reported by syzkaller:
BUG: memory leak
unreferenced object 0xffff888105df7000 (size 64):
comm "syz-executor842", pid 360, jiffies 4294824824 (age 22.546s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[&lt;00000000e67ed558&gt;] kmalloc include/linux/slab.h:590 [inline]
[&lt;00000000e67ed558&gt;] kzalloc include/linux/slab.h:720 [inline]
[&lt;00000000e67ed558&gt;] netlbl_cipsov4_add_std net/netlabel/netlabel_cipso_v4.c:145 [inline]
[&lt;00000000e67ed558&gt;] netlbl_cipsov4_add+0x390/0x2340 net/netlabel/netlabel_cipso_v4.c:416
[&lt;0000000006040154&gt;] genl_family_rcv_msg_doit.isra.0+0x20e/0x320 net/netlink/genetlink.c:739
[&lt;00000000204d7a1c&gt;] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
[&lt;00000000204d7a1c&gt;] genl_rcv_msg+0x2bf/0x4f0 net/netlink/genetlink.c:800
[&lt;00000000c0d6a995&gt;] netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2504
[&lt;00000000d78b9d2c&gt;] genl_rcv+0x24/0x40 net/netlink/genetlink.c:811
[&lt;000000009733081b&gt;] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
[&lt;000000009733081b&gt;] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1340
[&lt;00000000d5fd43b8&gt;] netlink_sendmsg+0x789/0xc70 net/netlink/af_netlink.c:1929
[&lt;000000000a2d1e40&gt;] sock_sendmsg_nosec net/socket.c:654 [inline]
[&lt;000000000a2d1e40&gt;] sock_sendmsg+0x139/0x170 net/socket.c:674
[&lt;00000000321d1969&gt;] ____sys_sendmsg+0x658/0x7d0 net/socket.c:2350
[&lt;00000000964e16bc&gt;] ___sys_sendmsg+0xf8/0x170 net/socket.c:2404
[&lt;000000001615e288&gt;] __sys_sendmsg+0xd3/0x190 net/socket.c:2433
[&lt;000000004ee8b6a5&gt;] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:47
[&lt;00000000171c7cee&gt;] entry_SYSCALL_64_after_hwframe+0x44/0xae

The memory of doi_def-&gt;map.std pointing is allocated in
netlbl_cipsov4_add_std, but no place has freed it. It should be
freed in cipso_v4_doi_free which frees the cipso DOI resource.</Note>
    </Notes>
    <CVE>CVE-2021-47250</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

batman-adv: Avoid WARN_ON timing related checks

The soft/batadv interface for a queued OGM can be changed during the time
the OGM was queued for transmission and when the OGM is actually
transmitted by the worker.

But WARN_ON must be used to denote kernel bugs and not to print simple
warnings. A warning can simply be printed using pr_warn.</Note>
    </Notes>
    <CVE>CVE-2021-47252</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gfs2: Fix use-after-free in gfs2_glock_shrink_scan

The GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() to
remove the glock from the lru list in __gfs2_glock_put().

On the shrink scan path, the same flag is cleared under lru_lock but because
of cond_resched_lock(&amp;lru_lock) in gfs2_dispose_glock_lru(), progress on the
put side can be made without deleting the glock from the lru list.

Keep GLF_LRU across the race window opened by cond_resched_lock(&amp;lru_lock) to
ensure correct behavior on both sides - clear GLF_LRU after list_del under
lru_lock.</Note>
    </Notes>
    <CVE>CVE-2021-47254</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: core: Fix error handling of scsi_host_alloc()

After device is initialized via device_initialize(), or its name is set via
dev_set_name(), the device has to be freed via put_device().  Otherwise
device name will be leaked because it is allocated dynamically in
dev_set_name().

Fix the leak by replacing kfree() with put_device(). Since
scsi_host_dev_release() properly handles IDA and kthread removal, remove
special-casing these from the error handling as well.</Note>
    </Notes>
    <CVE>CVE-2021-47258</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NFS: Fix a potential NULL dereference in nfs_get_client()

None of the callers are expecting NULL returns from nfs_get_client() so
this code will lead to an Oops.  It's better to return an error
pointer.  I expect that this is dead code so hopefully no one is
affected.</Note>
    </Notes>
    <CVE>CVE-2021-47260</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/mlx5: Fix initializing CQ fragments buffer

The function init_cq_frag_buf() can be called to initialize the current CQ
fragments buffer cq-&gt;buf, or the temporary cq-&gt;resize_buf that is filled
during CQ resize operation.

However, the offending commit started to use function get_cqe() for
getting the CQEs, the issue with this change is that get_cqe() always
returns CQEs from cq-&gt;buf, which leads us to initialize the wrong buffer,
and in case of enlarging the CQ we try to access elements beyond the size
of the current cq-&gt;buf and eventually hit a kernel panic.

 [exception RIP: init_cq_frag_buf+103]
  [ffff9f799ddcbcd8] mlx5_ib_resize_cq at ffffffffc0835d60 [mlx5_ib]
  [ffff9f799ddcbdb0] ib_resize_cq at ffffffffc05270df [ib_core]
  [ffff9f799ddcbdc0] llt_rdma_setup_qp at ffffffffc0a6a712 [llt]
  [ffff9f799ddcbe10] llt_rdma_cc_event_action at ffffffffc0a6b411 [llt]
  [ffff9f799ddcbe98] llt_rdma_client_conn_thread at ffffffffc0a6bb75 [llt]
  [ffff9f799ddcbec8] kthread at ffffffffa66c5da1
  [ffff9f799ddcbf50] ret_from_fork_nospec_begin at ffffffffa6d95ddd

Fix it by getting the needed CQE by calling mlx5_frag_buf_get_wqe() that
takes the correct source buffer as a parameter.</Note>
    </Notes>
    <CVE>CVE-2021-47261</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Verify port when creating flow rule

Validate port value provided by the user and with that remove no longer
needed validation by the driver.  The missing check in the mlx5_ib driver
could cause to the below oops.

Call trace:
  _create_flow_rule+0x2d4/0xf28 [mlx5_ib]
  mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]
  ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]
  ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]
  ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]
  ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]
  do_vfs_ioctl+0xd0/0xaf0
  ksys_ioctl+0x84/0xb4
  __arm64_sys_ioctl+0x28/0xc4
  el0_svc_common.constprop.3+0xa4/0x254
  el0_svc_handler+0x84/0xa0
  el0_svc+0x10/0x26c
 Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)</Note>
    </Notes>
    <CVE>CVE-2021-47265</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix various gadget panics on 10gbps cabling

usb_assign_descriptors() is called with 5 parameters,
the last 4 of which are the usb_descriptor_header for:
  full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps),
  high-speed (USB2.0 - 480Mbps),
  super-speed (USB3.0 - 5Gbps),
  super-speed-plus (USB3.1 - 10Gbps).

The differences between full/high/super-speed descriptors are usually
substantial (due to changes in the maximum usb block size from 64 to 512
to 1024 bytes and other differences in the specs), while the difference
between 5 and 10Gbps descriptors may be as little as nothing
(in many cases the same tuning is simply good enough).

However if a gadget driver calls usb_assign_descriptors() with
a NULL descriptor for super-speed-plus and is then used on a max 10gbps
configuration, the kernel will crash with a null pointer dereference,
when a 10gbps capable device port + cable + host port combination shows up.
(This wouldn't happen if the gadget max-speed was set to 5gbps, but
it of course defaults to the maximum, and there's no real reason to
artificially limit it)

The fix is to simply use the 5gbps descriptor as the 10gbps descriptor,
if a 10gbps descriptor wasn't provided.

Obviously this won't fix the problem if the 5gbps descriptor is also
NULL, but such cases can't be so trivially solved (and any such gadgets
are unlikely to be used with USB3 ports any way).</Note>
    </Notes>
    <CVE>CVE-2021-47267</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ep0: fix NULL pointer exception

There is no validation of the index from dwc3_wIndex_to_dep() and we might
be referring a non-existing ep and trigger a NULL pointer exception. In
certain configurations we might use fewer eps and the index might wrongly
indicate a larger ep index than existing.

By adding this validation from the patch we can actually report a wrong
index back to the caller.

In our usecase we are using a composite device on an older kernel, but
upstream might use this fix also. Unfortunately, I cannot describe the
hardware for others to reproduce the issue as it is a proprietary
implementation.

[   82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4
[   82.966891] Mem abort info:
[   82.969663]   ESR = 0x96000006
[   82.972703]   Exception class = DABT (current EL), IL = 32 bits
[   82.978603]   SET = 0, FnV = 0
[   82.981642]   EA = 0, S1PTW = 0
[   82.984765] Data abort info:
[   82.987631]   ISV = 0, ISS = 0x00000006
[   82.991449]   CM = 0, WnR = 0
[   82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc
[   83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000
[   83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP
[   83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c)
[   83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1
[   83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO)
[   83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c
[   83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94

...

[   83.141788] Call trace:
[   83.144227]  dwc3_ep0_handle_feature+0x414/0x43c
[   83.148823]  dwc3_ep0_interrupt+0x3b4/0xc94
[   83.181546] ---[ end trace aac6b5267d84c32f ]---</Note>
    </Notes>
    <CVE>CVE-2021-47269</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix various gadgets null ptr deref on 10gbps cabling.

This avoids a null pointer dereference in
f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm}
by simply reusing the 5gbps config for 10gbps.</Note>
    </Notes>
    <CVE>CVE-2021-47270</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Correct the length check which causes memory corruption

We've suffered from severe kernel crashes due to memory corruption on
our production environment, like,

Call Trace:
[1640542.554277] general protection fault: 0000 [#1] SMP PTI
[1640542.554856] CPU: 17 PID: 26996 Comm: python Kdump: loaded Tainted:G
[1640542.556629] RIP: 0010:kmem_cache_alloc+0x90/0x190
[1640542.559074] RSP: 0018:ffffb16faa597df8 EFLAGS: 00010286
[1640542.559587] RAX: 0000000000000000 RBX: 0000000000400200 RCX:
0000000006e931bf
[1640542.560323] RDX: 0000000006e931be RSI: 0000000000400200 RDI:
ffff9a45ff004300
[1640542.560996] RBP: 0000000000400200 R08: 0000000000023420 R09:
0000000000000000
[1640542.561670] R10: 0000000000000000 R11: 0000000000000000 R12:
ffffffff9a20608d
[1640542.562366] R13: ffff9a45ff004300 R14: ffff9a45ff004300 R15:
696c662f65636976
[1640542.563128] FS:  00007f45d7c6f740(0000) GS:ffff9a45ff840000(0000)
knlGS:0000000000000000
[1640542.563937] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[1640542.564557] CR2: 00007f45d71311a0 CR3: 000000189d63e004 CR4:
00000000003606e0
[1640542.565279] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[1640542.566069] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[1640542.566742] Call Trace:
[1640542.567009]  anon_vma_clone+0x5d/0x170
[1640542.567417]  __split_vma+0x91/0x1a0
[1640542.567777]  do_munmap+0x2c6/0x320
[1640542.568128]  vm_munmap+0x54/0x70
[1640542.569990]  __x64_sys_munmap+0x22/0x30
[1640542.572005]  do_syscall_64+0x5b/0x1b0
[1640542.573724]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[1640542.575642] RIP: 0033:0x7f45d6e61e27

James Wang has reproduced it stably on the latest 4.19 LTS.
After some debugging, we finally proved that it's due to ftrace
buffer out-of-bound access using a debug tool as follows:
[   86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000
[   86.780806]  no_context+0xdf/0x3c0
[   86.784327]  __do_page_fault+0x252/0x470
[   86.788367]  do_page_fault+0x32/0x140
[   86.792145]  page_fault+0x1e/0x30
[   86.795576]  strncpy_from_unsafe+0x66/0xb0
[   86.799789]  fetch_memory_string+0x25/0x40
[   86.804002]  fetch_deref_string+0x51/0x60
[   86.808134]  kprobe_trace_func+0x32d/0x3a0
[   86.812347]  kprobe_dispatcher+0x45/0x50
[   86.816385]  kprobe_ftrace_handler+0x90/0xf0
[   86.820779]  ftrace_ops_assist_func+0xa1/0x140
[   86.825340]  0xffffffffc00750bf
[   86.828603]  do_sys_open+0x5/0x1f0
[   86.832124]  do_syscall_64+0x5b/0x1b0
[   86.835900]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

commit b220c049d519 ("tracing: Check length before giving out
the filter buffer") adds length check to protect trace data
overflow introduced in 0fc1b09ff1ff, seems that this fix can't prevent
overflow entirely, the length check should also take the sizeof
entry-&gt;array[0] into account, since this array[0] is filled the
length of trace data and occupy addtional space and risk overflow.</Note>
    </Notes>
    <CVE>CVE-2021-47274</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bcache: avoid oversized read request in cache missing code path

In the cache missing code path of cached device, if a proper location
from the internal B+ tree is matched for a cache miss range, function
cached_dev_cache_miss() will be called in cache_lookup_fn() in the
following code block,
[code block 1]
  526         unsigned int sectors = KEY_INODE(k) == s-&gt;iop.inode
  527                 ? min_t(uint64_t, INT_MAX,
  528                         KEY_START(k) - bio-&gt;bi_iter.bi_sector)
  529                 : INT_MAX;
  530         int ret = s-&gt;d-&gt;cache_miss(b, s, bio, sectors);

Here s-&gt;d-&gt;cache_miss() is the call backfunction pointer initialized as
cached_dev_cache_miss(), the last parameter 'sectors' is an important
hint to calculate the size of read request to backing device of the
missing cache data.

Current calculation in above code block may generate oversized value of
'sectors', which consequently may trigger 2 different potential kernel
panics by BUG() or BUG_ON() as listed below,

1) BUG_ON() inside bch_btree_insert_key(),
[code block 2]
   886         BUG_ON(b-&gt;ops-&gt;is_extents &amp;&amp; !KEY_SIZE(k));
2) BUG() inside biovec_slab(),
[code block 3]
   51         default:
   52                 BUG();
   53                 return NULL;

All the above panics are original from cached_dev_cache_miss() by the
oversized parameter 'sectors'.

Inside cached_dev_cache_miss(), parameter 'sectors' is used to calculate
the size of data read from backing device for the cache missing. This
size is stored in s-&gt;insert_bio_sectors by the following lines of code,
[code block 4]
  909    s-&gt;insert_bio_sectors = min(sectors, bio_sectors(bio) + reada);

Then the actual key inserting to the internal B+ tree is generated and
stored in s-&gt;iop.replace_key by the following lines of code,
[code block 5]
  911   s-&gt;iop.replace_key = KEY(s-&gt;iop.inode,
  912                    bio-&gt;bi_iter.bi_sector + s-&gt;insert_bio_sectors,
  913                    s-&gt;insert_bio_sectors);
The oversized parameter 'sectors' may trigger panic 1) by BUG_ON() from
the above code block.

And the bio sending to backing device for the missing data is allocated
with hint from s-&gt;insert_bio_sectors by the following lines of code,
[code block 6]
  926    cache_bio = bio_alloc_bioset(GFP_NOWAIT,
  927                 DIV_ROUND_UP(s-&gt;insert_bio_sectors, PAGE_SECTORS),
  928                 &amp;dc-&gt;disk.bio_split);
The oversized parameter 'sectors' may trigger panic 2) by BUG() from the
agove code block.

Now let me explain how the panics happen with the oversized 'sectors'.
In code block 5, replace_key is generated by macro KEY(). From the
definition of macro KEY(),
[code block 7]
  71 #define KEY(inode, offset, size)                                  \
  72 ((struct bkey) {                                                  \
  73      .high = (1ULL &lt;&lt; 63) | ((__u64) (size) &lt;&lt; 20) | (inode),     \
  74      .low = (offset)                                              \
  75 })

Here 'size' is 16bits width embedded in 64bits member 'high' of struct
bkey. But in code block 1, if "KEY_START(k) - bio-&gt;bi_iter.bi_sector" is
very probably to be larger than (1&lt;&lt;16) - 1, which makes the bkey size
calculation in code block 5 is overflowed. In one bug report the value
of parameter 'sectors' is 131072 (= 1 &lt;&lt; 17), the overflowed 'sectors'
results the overflowed s-&gt;insert_bio_sectors in code block 4, then makes
size field of s-&gt;iop.replace_key to be 0 in code block 5. Then the 0-
sized s-&gt;iop.replace_key is inserted into the internal B+ tree as cache
missing check key (a special key to detect and avoid a racing between
normal write request and cache missing read request) as,
[code block 8]
  915   ret = bch_btree_insert_check_key(b, &amp;s-&gt;op, &amp;s-&gt;iop.replace_key);

Then the 0-sized s-&gt;iop.replace_key as 3rd parameter triggers the bkey
size check BUG_ON() in code block 2, and causes the kernel panic 1).

Another ke
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47275</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ftrace: Do not blindly read the ip address in ftrace_bug()

It was reported that a bug on arm64 caused a bad ip address to be used for
updating into a nop in ftrace_init(), but the error path (rightfully)
returned -EINVAL and not -EFAULT, as the bug caused more than one error to
occur. But because -EINVAL was returned, the ftrace_bug() tried to report
what was at the location of the ip address, and read it directly. This
caused the machine to panic, as the ip was not pointing to a valid memory
address.

Instead, read the ip address with copy_from_kernel_nofault() to safely
access the memory, and if it faults, report that the address faulted,
otherwise report what was in that location.</Note>
    </Notes>
    <CVE>CVE-2021-47276</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: avoid speculation-based attacks from out-of-range memslot accesses

KVM's mechanism for accessing guest memory translates a guest physical
address (gpa) to a host virtual address using the right-shifted gpa
(also known as gfn) and a struct kvm_memory_slot.  The translation is
performed in __gfn_to_hva_memslot using the following formula:

      hva = slot-&gt;userspace_addr + (gfn - slot-&gt;base_gfn) * PAGE_SIZE

It is expected that gfn falls within the boundaries of the guest's
physical memory.  However, a guest can access invalid physical addresses
in such a way that the gfn is invalid.

__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first
retrieves a memslot through __gfn_to_memslot.  While __gfn_to_memslot
does check that the gfn falls within the boundaries of the guest's
physical memory or not, a CPU can speculate the result of the check and
continue execution speculatively using an illegal gfn. The speculation
can result in calculating an out-of-bounds hva.  If the resulting host
virtual address is used to load another guest physical address, this
is effectively a Spectre gadget consisting of two consecutive reads,
the second of which is data dependent on the first.

Right now it's not clear if there are any cases in which this is
exploitable.  One interesting case was reported by the original author
of this patch, and involves visiting guest page tables on x86.  Right
now these are not vulnerable because the hva read goes through get_user(),
which contains an LFENCE speculation barrier.  However, there are
patches in progress for x86 uaccess.h to mask kernel addresses instead of
using LFENCE; once these land, a guest could use speculation to read
from the VMM's ring 3 address space.  Other architectures such as ARM
already use the address masking method, and would be susceptible to
this same kind of data-dependent access gadgets.  Therefore, this patch
proactively protects from these attacks by masking out-of-bounds gfns
in __gfn_to_hva_memslot, which blocks speculation of invalid hvas.

Sean Christopherson noted that this patch does not cover
kvm_read_guest_offset_cached.  This however is limited to a few bytes
past the end of the cache, and therefore it is unlikely to be useful in
the context of building a chain of data dependent accesses.</Note>
    </Notes>
    <CVE>CVE-2021-47277</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix use-after-free read in drm_getunique()

There is a time-of-check-to-time-of-use error in drm_getunique() due
to retrieving file_priv-&gt;master prior to locking the device's master
mutex.

An example can be seen in the crash report of the use-after-free error
found by Syzbot:
https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803

In the report, the master pointer was used after being freed. This is
because another process had acquired the device's master mutex in
drm_setmaster_ioctl(), then overwrote fpriv-&gt;master in
drm_new_set_master(). The old value of fpriv-&gt;master was subsequently
freed before the mutex was unlocked.

To fix this, we lock the device's master mutex before retrieving the
pointer from from fpriv-&gt;master. This patch passes the Syzbot
reproducer test.</Note>
    </Notes>
    <CVE>CVE-2021-47280</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: seq: Fix race of snd_seq_timer_open()

The timer instance per queue is exclusive, and snd_seq_timer_open()
should have managed the concurrent accesses.  It looks as if it's
checking the already existing timer instance at the beginning, but
it's not right, because there is no protection, hence any later
concurrent call of snd_seq_timer_open() may override the timer
instance easily.  This may result in UAF, as the leftover timer
instance can keep running while the queue itself gets closed, as
spotted by syzkaller recently.

For avoiding the race, add a proper check at the assignment of
tmr-&gt;timeri again, and return -EBUSY if it's been already registered.</Note>
    </Notes>
    <CVE>CVE-2021-47281</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: netjet: Fix crash in nj_probe:

'nj_setup' in netjet.c might fail with -EIO and in this case
'card-&gt;irq' is initialized and is bigger than zero. A subsequent call to
'nj_release' will free the irq that has not been requested.

Fix this bug by deleting the previous assignment to 'card-&gt;irq' and just
keep the assignment before 'request_irq'.

The KASAN's log reveals it:

[    3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826
free_irq+0x100/0x480
[    3.355112 ] Modules linked in:
[    3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.13.0-rc1-00144-g25a1298726e #13
[    3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[    3.356552 ] RIP: 0010:free_irq+0x100/0x480
[    3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18
4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5
ff &lt;0f&gt; 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80
[    3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082
[    3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX:
0000000000000000
[    3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI:
00000000ffffffff
[    3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09:
0000000000000000
[    3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12:
0000000000000000
[    3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15:
ffff888104dc80a8
[    3.360652 ] FS:  0000000000000000(0000) GS:ffff88817bc00000(0000)
knlGS:0000000000000000
[    3.361170 ] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4:
00000000000006f0
[    3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[    3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[    3.362175 ] Call Trace:
[    3.362175 ]  nj_release+0x51/0x1e0
[    3.362175 ]  nj_probe+0x450/0x950
[    3.362175 ]  ? pci_device_remove+0x110/0x110
[    3.362175 ]  local_pci_probe+0x45/0xa0
[    3.362175 ]  pci_device_probe+0x12b/0x1d0
[    3.362175 ]  really_probe+0x2a9/0x610
[    3.362175 ]  driver_probe_device+0x90/0x1d0
[    3.362175 ]  ? mutex_lock_nested+0x1b/0x20
[    3.362175 ]  device_driver_attach+0x68/0x70
[    3.362175 ]  __driver_attach+0x124/0x1b0
[    3.362175 ]  ? device_driver_attach+0x70/0x70
[    3.362175 ]  bus_for_each_dev+0xbb/0x110
[    3.362175 ]  ? rdinit_setup+0x45/0x45
[    3.362175 ]  driver_attach+0x27/0x30
[    3.362175 ]  bus_add_driver+0x1eb/0x2a0
[    3.362175 ]  driver_register+0xa9/0x180
[    3.362175 ]  __pci_register_driver+0x82/0x90
[    3.362175 ]  ? w6692_init+0x38/0x38
[    3.362175 ]  nj_init+0x36/0x38
[    3.362175 ]  do_one_initcall+0x7f/0x3d0
[    3.362175 ]  ? rdinit_setup+0x45/0x45
[    3.362175 ]  ? rcu_read_lock_sched_held+0x4f/0x80
[    3.362175 ]  kernel_init_freeable+0x2aa/0x301
[    3.362175 ]  ? rest_init+0x2c0/0x2c0
[    3.362175 ]  kernel_init+0x18/0x190
[    3.362175 ]  ? rest_init+0x2c0/0x2c0
[    3.362175 ]  ? rest_init+0x2c0/0x2c0
[    3.362175 ]  ret_from_fork+0x1f/0x30
[    3.362175 ] Kernel panic - not syncing: panic_on_warn set ...
[    3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.13.0-rc1-00144-g25a1298726e #13
[    3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[    3.362175 ] Call Trace:
[    3.362175 ]  dump_stack+0xba/0xf5
[    3.362175 ]  ? free_irq+0x100/0x480
[    3.362175 ]  panic+0x15a/0x3f2
[    3.362175 ]  ? __warn+0xf2/0x150
[    3.362175 ]  ? free_irq+0x100/0x480
[    3.362175 ]  __warn+0x108/0x150
[    3.362175 ]  ? free_irq+0x100/0x480
[    3.362175 ]  report_bug+0x119/0x1c0
[    3.362175 ]  handle_bug+0x3b/0x80
[    3.362175 ]  exc_invalid_op+0x18/0x70
[    3.362175 ]  asm_exc_invalid_op+0x12/0x20
[    3.362175 ] RIP: 0010:free_irq+0x100
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47284</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-2021-47285</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()

Fix an 11-year old bug in ngene_command_config_free_buf() while
addressing the following warnings caught with -Warray-bounds:

arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]
arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]

The problem is that the original code is trying to copy 6 bytes of
data into a one-byte size member _config_ of the wrong structue
FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a
legitimate compiler warning because memcpy() overruns the length
of &amp;com.cmd.ConfigureBuffers.config. It seems that the right
structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains
6 more members apart from the header _hdr_. Also, the name of
the function ngene_command_config_free_buf() suggests that the actual
intention is to ConfigureFreeBuffers, instead of ConfigureBuffers
(which takes place in the function ngene_command_config_buf(), above).

Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS
into new struct config, and use &amp;com.cmd.ConfigureFreeBuffers.config as
the destination address, instead of &amp;com.cmd.ConfigureBuffers.config,
when calling memcpy().

This also helps with the ongoing efforts to globally enable
-Warray-bounds and get us closer to being able to tighten the
FORTIFY_SOURCE routines on memcpy().</Note>
    </Notes>
    <CVE>CVE-2021-47288</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Skip non-Ethernet packets

Currently tcf_skbmod_act() assumes that packets use Ethernet as their L2
protocol, which is not always the case.  As an example, for CAN devices:

	$ ip link add dev vcan0 type vcan
	$ ip link set up vcan0
	$ tc qdisc add dev vcan0 root handle 1: htb
	$ tc filter add dev vcan0 parent 1: protocol ip prio 10 \
		matchall action skbmod swap mac

Doing the above silently corrupts all the packets.  Do not perform skbmod
actions for non-Ethernet packets.</Note>
    </Notes>
    <CVE>CVE-2021-47293</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netrom: Decrease sock refcount when sock timers expire

Commit 63346650c1a9 ("netrom: switch to sock timer API") switched to use
sock timer API. It replaces mod_timer() by sk_reset_timer(), and
del_timer() by sk_stop_timer().

Function sk_reset_timer() will increase the refcount of sock if it is
called on an inactive timer, hence, in case the timer expires, we need to
decrease the refcount ourselves in the handler, otherwise, the sock
refcount will be unbalanced and the sock will never be freed.</Note>
    </Notes>
    <CVE>CVE-2021-47294</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 uninit-value in caif_seqpkt_sendmsg

When nr_segs equal to zero in iovec_from_user, the object
msg-&gt;msg_iter.iov is uninit stack memory in caif_seqpkt_sendmsg
which is defined in ___sys_sendmsg. So we cann't just judge
msg-&gt;msg_iter.iov-&gt;base directlly. We can use nr_segs to judge
msg in caif_seqpkt_sendmsg whether has data buffers.

=====================================================
BUG: KMSAN: uninit-value in caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1c9/0x220 lib/dump_stack.c:118
 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
 caif_seqpkt_sendmsg+0x693/0xf60 net/caif/caif_socket.c:542
 sock_sendmsg_nosec net/socket.c:652 [inline]
 sock_sendmsg net/socket.c:672 [inline]
 ____sys_sendmsg+0x12b6/0x1350 net/socket.c:2343
 ___sys_sendmsg net/socket.c:2397 [inline]
 __sys_sendmmsg+0x808/0xc90 net/socket.c:2480
 __compat_sys_sendmmsg net/compat.c:656 [inline]</Note>
    </Notes>
    <CVE>CVE-2021-47297</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix use-after-free error during reset

Cleans the next descriptor to watch (next_to_watch) when cleaning the
TX ring.

Failure to do so can cause invalid memory accesses. If igb_poll() runs
while the controller is reset this can lead to the driver try to free
a skb that was already freed.

(The crash is harder to reproduce with the igb driver, but the same
potential problem exists as the code is identical to igc)</Note>
    </Notes>
    <CVE>CVE-2021-47301</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

igc: Fix use-after-free error during reset

Cleans the next descriptor to watch (next_to_watch) when cleaning the
TX ring.

Failure to do so can cause invalid memory accesses. If igc_poll() runs
while the controller is being reset this can lead to the driver try to
free a skb that was already freed.

Log message:

 [  101.525242] refcount_t: underflow; use-after-free.
 [  101.525251] WARNING: CPU: 1 PID: 646 at lib/refcount.c:28 refcount_warn_saturate+0xab/0xf0
 [  101.525259] Modules linked in: sch_etf(E) sch_mqprio(E) rfkill(E) intel_rapl_msr(E) intel_rapl_common(E)
 x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) binfmt_misc(E) kvm_intel(E) kvm(E) irqbypass(E) crc32_pclmul(E)
 ghash_clmulni_intel(E) aesni_intel(E) mei_wdt(E) libaes(E) crypto_simd(E) cryptd(E) glue_helper(E) snd_hda_codec_hdmi(E)
 rapl(E) intel_cstate(E) snd_hda_intel(E) snd_intel_dspcfg(E) sg(E) soundwire_intel(E) intel_uncore(E) at24(E)
 soundwire_generic_allocation(E) iTCO_wdt(E) soundwire_cadence(E) intel_pmc_bxt(E) serio_raw(E) snd_hda_codec(E)
 iTCO_vendor_support(E) watchdog(E) snd_hda_core(E) snd_hwdep(E) snd_soc_core(E) snd_compress(E) snd_pcsp(E)
 soundwire_bus(E) snd_pcm(E) evdev(E) snd_timer(E) mei_me(E) snd(E) soundcore(E) mei(E) configfs(E) ip_tables(E) x_tables(E)
 autofs4(E) ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E)
 i915(E) ahci(E) libahci(E) ehci_pci(E) igb(E) xhci_pci(E) ehci_hcd(E)
 [  101.525303]  drm_kms_helper(E) dca(E) xhci_hcd(E) libata(E) crct10dif_pclmul(E) cec(E) crct10dif_common(E) tsn(E) igc(E)
 e1000e(E) ptp(E) i2c_i801(E) crc32c_intel(E) psmouse(E) i2c_algo_bit(E) i2c_smbus(E) scsi_mod(E) lpc_ich(E) pps_core(E)
 usbcore(E) drm(E) button(E) video(E)
 [  101.525318] CPU: 1 PID: 646 Comm: irq/37-enp7s0-T Tainted: G            E     5.10.30-rt37-tsn1-rt-ipipe #ipipe
 [  101.525320] Hardware name: SIEMENS AG SIMATIC IPC427D/A5E31233588, BIOS V17.02.09 03/31/2017
 [  101.525322] RIP: 0010:refcount_warn_saturate+0xab/0xf0
 [  101.525325] Code: 05 31 48 44 01 01 e8 f0 c6 42 00 0f 0b c3 80 3d 1f 48 44 01 00 75 90 48 c7 c7 78 a8 f3 a6 c6 05 0f 48
 44 01 01 e8 d1 c6 42 00 &lt;0f&gt; 0b c3 80 3d fe 47 44 01 00 0f 85 6d ff ff ff 48 c7 c7 d0 a8 f3
 [  101.525327] RSP: 0018:ffffbdedc0917cb8 EFLAGS: 00010286
 [  101.525329] RAX: 0000000000000000 RBX: ffff98fd6becbf40 RCX: 0000000000000001
 [  101.525330] RDX: 0000000000000001 RSI: ffffffffa6f2700c RDI: 00000000ffffffff
 [  101.525332] RBP: ffff98fd6becc14c R08: ffffffffa7463d00 R09: ffffbdedc0917c50
 [  101.525333] R10: ffffffffa74c3578 R11: 0000000000000034 R12: 00000000ffffff00
 [  101.525335] R13: ffff98fd6b0b1000 R14: 0000000000000039 R15: ffff98fd6be35c40
 [  101.525337] FS:  0000000000000000(0000) GS:ffff98fd6e240000(0000) knlGS:0000000000000000
 [  101.525339] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 [  101.525341] CR2: 00007f34135a3a70 CR3: 0000000150210003 CR4: 00000000001706e0
 [  101.525343] Call Trace:
 [  101.525346]  sock_wfree+0x9c/0xa0
 [  101.525353]  unix_destruct_scm+0x7b/0xa0
 [  101.525358]  skb_release_head_state+0x40/0x90
 [  101.525362]  skb_release_all+0xe/0x30
 [  101.525364]  napi_consume_skb+0x57/0x160
 [  101.525367]  igc_poll+0xb7/0xc80 [igc]
 [  101.525376]  ? sched_clock+0x5/0x10
 [  101.525381]  ? sched_clock_cpu+0xe/0x100
 [  101.525385]  net_rx_action+0x14c/0x410
 [  101.525388]  __do_softirq+0xe9/0x2f4
 [  101.525391]  __local_bh_enable_ip+0xe3/0x110
 [  101.525395]  ? irq_finalize_oneshot.part.47+0xe0/0xe0
 [  101.525398]  irq_forced_thread_fn+0x6a/0x80
 [  101.525401]  irq_thread+0xe8/0x180
 [  101.525403]  ? wake_threads_waitq+0x30/0x30
 [  101.525406]  ? irq_thread_check_affinity+0xd0/0xd0
 [  101.525408]  kthread+0x183/0x1a0
 [  101.525412]  ? kthread_park+0x80/0x80
 [  101.525415]  ret_from_fork+0x22/0x30</Note>
    </Notes>
    <CVE>CVE-2021-47302</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-buf/sync_file: Don't leak fences on merge failure

Each add_fence() call does a dma_fence_get() on the relevant fence.  In
the error path, we weren't calling dma_fence_put() so all those fences
got leaked.  Also, in the krealloc_array failure case, we weren't
freeing the fences array.  Instead, ensure that i and fences are always
zero-initialized and dma_fence_put() all the fences and kfree(fences) on
every error path.</Note>
    </Notes>
    <CVE>CVE-2021-47305</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: prevent NULL deref in cifs_compose_mount_options()

The optional @ref parameter might contain an NULL node_name, so
prevent dereferencing it in cifs_compose_mount_options().

Addresses-Coverity: 1476408 ("Explicit null dereferenced")</Note>
    </Notes>
    <CVE>CVE-2021-47307</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: libfc: Fix array index out of bound exception

Fix array index out of bound exception in fc_rport_prli_resp().</Note>
    </Notes>
    <CVE>CVE-2021-47308</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: validate lwtstate-&gt;data before returning from skb_tunnel_info()

skb_tunnel_info() returns pointer of lwtstate-&gt;data as ip_tunnel_info
type without validation. lwtstate-&gt;data can have various types such as
mpls_iptunnel_encap, etc and these are not compatible.
So skb_tunnel_info() should validate before returning that pointer.

Splat looks like:
BUG: KASAN: slab-out-of-bounds in vxlan_get_route+0x418/0x4b0 [vxlan]
Read of size 2 at addr ffff888106ec2698 by task ping/811

CPU: 1 PID: 811 Comm: ping Not tainted 5.13.0+ #1195
Call Trace:
 dump_stack_lvl+0x56/0x7b
 print_address_description.constprop.8.cold.13+0x13/0x2ee
 ? vxlan_get_route+0x418/0x4b0 [vxlan]
 ? vxlan_get_route+0x418/0x4b0 [vxlan]
 kasan_report.cold.14+0x83/0xdf
 ? vxlan_get_route+0x418/0x4b0 [vxlan]
 vxlan_get_route+0x418/0x4b0 [vxlan]
 [ ... ]
 vxlan_xmit_one+0x148b/0x32b0 [vxlan]
 [ ... ]
 vxlan_xmit+0x25c5/0x4780 [vxlan]
 [ ... ]
 dev_hard_start_xmit+0x1ae/0x6e0
 __dev_queue_xmit+0x1f39/0x31a0
 [ ... ]
 neigh_xmit+0x2f9/0x940
 mpls_xmit+0x911/0x1600 [mpls_iptunnel]
 lwtunnel_xmit+0x18f/0x450
 ip_finish_output2+0x867/0x2040
 [ ... ]</Note>
    </Notes>
    <CVE>CVE-2021-47309</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ti: fix UAF in tlan_remove_one

priv is netdev private data and it cannot be
used after free_netdev() call. Using priv after free_netdev()
can cause UAF bug. Fix it by moving free_netdev() at the end of the
function.</Note>
    </Notes>
    <CVE>CVE-2021-47310</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qcom/emac: fix UAF in emac_remove

adpt is netdev private data and it cannot be
used after free_netdev() call. Using adpt after free_netdev()
can cause UAF bug. Fix it by moving free_netdev() at the end of the
function.</Note>
    </Notes>
    <CVE>CVE-2021-47311</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

memory: fsl_ifc: fix leak of private memory on probe failure

On probe error the driver should free the memory allocated for private
structure.  Fix this by using resource-managed allocation.</Note>
    </Notes>
    <CVE>CVE-2021-47314</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

memory: fsl_ifc: fix leak of IO mapping on probe failure

On probe error the driver should unmap the IO memory.  Smatch reports:

  drivers/memory/fsl_ifc.c:298 fsl_ifc_ctrl_probe() warn: 'fsl_ifc_ctrl_dev-&gt;gregs' not released on lines: 298.</Note>
    </Notes>
    <CVE>CVE-2021-47315</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

virtio-blk: Fix memory leak among suspend/resume procedure

The vblk-&gt;vqs should be freed before we call init_vqs()
in virtblk_restore().</Note>
    </Notes>
    <CVE>CVE-2021-47319</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfs: fix acl memory leak of posix_acl_create()

When looking into another nfs xfstests report, I found acl and
default_acl in nfs3_proc_create() and nfs3_proc_mknod() error
paths are possibly leaked. Fix them in advance.</Note>
    </Notes>
    <CVE>CVE-2021-47320</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

watchdog: Fix possible use-after-free by calling del_timer_sync()

This driver's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.

Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.</Note>
    </Notes>
    <CVE>CVE-2021-47321</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

watchdog: sc520_wdt: Fix possible use-after-free in wdt_turnoff()

This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.

Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.</Note>
    </Notes>
    <CVE>CVE-2021-47323</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

watchdog: Fix possible use-after-free in wdt_startup()

This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.

Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.</Note>
    </Notes>
    <CVE>CVE-2021-47324</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: iscsi: Fix conn use after free during resets

If we haven't done a unbind target call we can race where
iscsi_conn_teardown wakes up the EH thread and then frees the conn while
those threads are still accessing the conn ehwait.

We can only do one TMF per session so this just moves the TMF fields from
the conn to the session. We can then rely on the
iscsi_session_teardown-&gt;iscsi_remove_session-&gt;__iscsi_unbind_session call
to remove the target and it's devices, and know after that point there is
no device or scsi-ml callout trying to access the session.</Note>
    </Notes>
    <CVE>CVE-2021-47328</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tty: serial: 8250: serial_cs: Fix a memory leak in error handling path

In the probe function, if the final 'serial_config()' fails, 'info' is
leaking.

Add a resource handling path to free this memory.</Note>
    </Notes>
    <CVE>CVE-2021-47330</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

misc/libmasm/module: Fix two use after free in ibmasm_init_one

In ibmasm_init_one, it calls ibmasm_init_remote_input_dev().
Inside ibmasm_init_remote_input_dev, mouse_dev and keybd_dev are
allocated by input_allocate_device(), and assigned to
sp-&gt;remote.mouse_dev and sp-&gt;remote.keybd_dev respectively.

In the err_free_devices error branch of ibmasm_init_one,
mouse_dev and keybd_dev are freed by input_free_device(), and return
error. Then the execution runs into error_send_message error branch
of ibmasm_init_one, where ibmasm_free_remote_input_dev(sp) is called
to unregister the freed sp-&gt;remote.mouse_dev and sp-&gt;remote.keybd_dev.

My patch add a "error_init_remote" label to handle the error of
ibmasm_init_remote_input_dev(), to avoid the uaf bugs.</Note>
    </Notes>
    <CVE>CVE-2021-47334</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: core: Fix bad pointer dereference when ehandler kthread is invalid

Commit 66a834d09293 ("scsi: core: Fix error handling of scsi_host_alloc()")
changed the allocation logic to call put_device() to perform host cleanup
with the assumption that IDA removal and stopping the kthread would
properly be performed in scsi_host_dev_release(). However, in the unlikely
case that the error handler thread fails to spawn, shost-&gt;ehandler is set
to ERR_PTR(-ENOMEM).

The error handler cleanup code in scsi_host_dev_release() will call
kthread_stop() if shost-&gt;ehandler != NULL which will always be the case
whether the kthread was successfully spawned or not. In the case that it
failed to spawn this has the nasty side effect of trying to dereference an
invalid pointer when kthread_stop() is called. The following splat provides
an example of this behavior in the wild:

scsi host11: error handler thread failed to spawn, error = -4
Kernel attempted to read user page (10c) - exploit attempt? (uid: 0)
BUG: Kernel NULL pointer dereference on read at 0x0000010c
Faulting instruction address: 0xc00000000818e9a8
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: ibmvscsi(+) scsi_transport_srp dm_multipath dm_mirror dm_region
 hash dm_log dm_mod fuse overlay squashfs loop
CPU: 12 PID: 274 Comm: systemd-udevd Not tainted 5.13.0-rc7 #1
NIP:  c00000000818e9a8 LR: c0000000089846e8 CTR: 0000000000007ee8
REGS: c000000037d12ea0 TRAP: 0300   Not tainted  (5.13.0-rc7)
MSR:  800000000280b033 &amp;lt;SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE&amp;gt;  CR: 28228228
XER: 20040001
CFAR: c0000000089846e4 DAR: 000000000000010c DSISR: 40000000 IRQMASK: 0
GPR00: c0000000089846e8 c000000037d13140 c000000009cc1100 fffffffffffffffc
GPR04: 0000000000000001 0000000000000000 0000000000000000 c000000037dc0000
GPR08: 0000000000000000 c000000037dc0000 0000000000000001 00000000fffff7ff
GPR12: 0000000000008000 c00000000a049000 c000000037d13d00 000000011134d5a0
GPR16: 0000000000001740 c0080000190d0000 c0080000190d1740 c000000009129288
GPR20: c000000037d13bc0 0000000000000001 c000000037d13bc0 c0080000190b7898
GPR24: c0080000190b7708 0000000000000000 c000000033bb2c48 0000000000000000
GPR28: c000000046b28280 0000000000000000 000000000000010c fffffffffffffffc
NIP [c00000000818e9a8] kthread_stop+0x38/0x230
LR [c0000000089846e8] scsi_host_dev_release+0x98/0x160
Call Trace:
[c000000033bb2c48] 0xc000000033bb2c48 (unreliable)
[c0000000089846e8] scsi_host_dev_release+0x98/0x160
[c00000000891e960] device_release+0x60/0x100
[c0000000087e55c4] kobject_release+0x84/0x210
[c00000000891ec78] put_device+0x28/0x40
[c000000008984ea4] scsi_host_alloc+0x314/0x430
[c0080000190b38bc] ibmvscsi_probe+0x54/0xad0 [ibmvscsi]
[c000000008110104] vio_bus_probe+0xa4/0x4b0
[c00000000892a860] really_probe+0x140/0x680
[c00000000892aefc] driver_probe_device+0x15c/0x200
[c00000000892b63c] device_driver_attach+0xcc/0xe0
[c00000000892b740] __driver_attach+0xf0/0x200
[c000000008926f28] bus_for_each_dev+0xa8/0x130
[c000000008929ce4] driver_attach+0x34/0x50
[c000000008928fc0] bus_add_driver+0x1b0/0x300
[c00000000892c798] driver_register+0x98/0x1a0
[c00000000810eb60] __vio_register_driver+0x80/0xe0
[c0080000190b4a30] ibmvscsi_module_init+0x9c/0xdc [ibmvscsi]
[c0000000080121d0] do_one_initcall+0x60/0x2d0
[c000000008261abc] do_init_module+0x7c/0x320
[c000000008265700] load_module+0x2350/0x25b0
[c000000008265cb4] __do_sys_finit_module+0xd4/0x160
[c000000008031110] system_call_exception+0x150/0x2d0
[c00000000800d35c] system_call_common+0xec/0x278

Fix this be nulling shost-&gt;ehandler when the kthread fails to spawn.</Note>
    </Notes>
    <CVE>CVE-2021-47337</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 btree remove: assign new_root only when removal succeeds

remove_raw() in dm_btree_remove() may fail due to IO read error
(e.g. read the content of origin block fails during shadowing),
and the value of shadow_spine::root is uninitialized, but
the uninitialized value is still assign to new_root in the
end of dm_btree_remove().

For dm-thin, the value of pmd-&gt;details_root or pmd-&gt;root will become
an uninitialized value, so if trying to read details_info tree again
out-of-bound memory may occur as showed below:

  general protection fault, probably for non-canonical address 0x3fdcb14c8d7520
  CPU: 4 PID: 515 Comm: dmsetup Not tainted 5.13.0-rc6
  Hardware name: QEMU Standard PC
  RIP: 0010:metadata_ll_load_ie+0x14/0x30
  Call Trace:
   sm_metadata_count_is_more_than_one+0xb9/0xe0
   dm_tm_shadow_block+0x52/0x1c0
   shadow_step+0x59/0xf0
   remove_raw+0xb2/0x170
   dm_btree_remove+0xf4/0x1c0
   dm_pool_delete_thin_device+0xc3/0x140
   pool_message+0x218/0x2b0
   target_message+0x251/0x290
   ctl_ioctl+0x1c4/0x4d0
   dm_ctl_ioctl+0xe/0x20
   __x64_sys_ioctl+0x7b/0xb0
   do_syscall_64+0x40/0xb0
   entry_SYSCALL_64_after_hwframe+0x44/0xae

Fixing it by only assign new_root when removal succeeds</Note>
    </Notes>
    <CVE>CVE-2021-47343</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: zr364xx: fix memory leak in zr364xx_start_readpipe

syzbot reported memory leak in zr364xx driver.
The problem was in non-freed urb in case of
usb_submit_urb() fail.

backtrace:
  [&lt;ffffffff82baedf6&gt;] kmalloc include/linux/slab.h:561 [inline]
  [&lt;ffffffff82baedf6&gt;] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74
  [&lt;ffffffff82f7cce8&gt;] zr364xx_start_readpipe+0x78/0x130 drivers/media/usb/zr364xx/zr364xx.c:1022
  [&lt;ffffffff84251dfc&gt;] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [inline]
  [&lt;ffffffff84251dfc&gt;] zr364xx_probe+0x6a3/0x851 drivers/media/usb/zr364xx/zr364xx.c:1516
  [&lt;ffffffff82bb6507&gt;] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
  [&lt;ffffffff826018a9&gt;] really_probe+0x159/0x500 drivers/base/dd.c:576</Note>
    </Notes>
    <CVE>CVE-2021-47344</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/cma: Fix rdma_resolve_route() memory leak

Fix a memory leak when "mda_resolve_route() is called more than once on
the same "rdma_cm_id".

This is possible if cma_query_handler() triggers the
RDMA_CM_EVENT_ROUTE_ERROR flow which puts the state machine back and
allows rdma_resolve_route() to be called again.</Note>
    </Notes>
    <CVE>CVE-2021-47345</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wl1251: Fix possible buffer overflow in wl1251_cmd_scan

Function wl1251_cmd_scan calls memcpy without checking the length.
Harden by checking the length is within the maximum allowed size.</Note>
    </Notes>
    <CVE>CVE-2021-47347</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

virtio-net: Add validation for used length

This adds validation for used length (might come
from an untrusted device) to avoid data corruption
or loss.</Note>
    </Notes>
    <CVE>CVE-2021-47352</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 NULL pointer dereference in udf_symlink function

In function udf_symlink, epos.bh is assigned with the value returned
by udf_tgetblk. The function udf_tgetblk is defined in udf/misc.c
and returns the value of sb_getblk function that could be NULL.
Then, epos.bh is used without any check, causing a possible
NULL pointer dereference when sb_getblk fails.

This fix adds a check to validate the value of epos.bh.</Note>
    </Notes>
    <CVE>CVE-2021-47353</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/sched: Avoid data corruptions

Wait for all dependencies of a job  to complete before
killing it to avoid data corruptions.</Note>
    </Notes>
    <CVE>CVE-2021-47354</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: nicstar: Fix possible use-after-free in nicstar_cleanup()

This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.

Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.</Note>
    </Notes>
    <CVE>CVE-2021-47355</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 possible use-after-free in HFC_cleanup()

This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.

Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.</Note>
    </Notes>
    <CVE>CVE-2021-47356</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: iphase: fix possible use-after-free in ia_module_exit()

This module's remove path calls del_timer(). However, that function
does not wait until the timer handler finishes. This means that the
timer handler may still be running after the driver's remove function
has finished, which would result in a use-after-free.

Fix by calling del_timer_sync(), which makes sure the timer handler
has finished, and unable to re-schedule itself.</Note>
    </Notes>
    <CVE>CVE-2021-47357</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mcb: fix error handling in mcb_alloc_bus()

There are two bugs:
1) If ida_simple_get() fails then this code calls put_device(carrier)
   but we haven't yet called get_device(carrier) and probably that
   leads to a use after free.
2) After device_initialize() then we need to use put_device() to
   release the bus.  This will free the internal resources tied to the
   device and call mcb_free_bus() which will free the rest.</Note>
    </Notes>
    <CVE>CVE-2021-47361</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Update intermediate power state for SI

Update the current state as boot state during dpm initialization.
During the subsequent initialization, set_power_state gets called to
transition to the final power state. set_power_state refers to values
from the current state and without current state populated, it could
result in NULL pointer dereference.

For ex: on platforms where PCI speed change is supported through ACPI
ATCS method, the link speed of current state needs to be queried before
deciding on changing to final power state's link speed. The logic to query
ATCS-support was broken on certain platforms. The issue became visible
when broken ATCS-support logic got fixed with commit
f9b7f3703ff9 ("drm/amdgpu/acpi: make ATPX/ATCS structures global (v2)").

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1698</Note>
    </Notes>
    <CVE>CVE-2021-47362</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/qeth: fix NULL deref in qeth_clear_working_pool_list()

When qeth_set_online() calls qeth_clear_working_pool_list() to roll
back after an error exit from qeth_hardsetup_card(), we are at risk of
accessing card-&gt;qdio.in_q before it was allocated by
qeth_alloc_qdio_queues() via qeth_mpc_initialize().

qeth_clear_working_pool_list() then dereferences NULL, and by writing to
queue-&gt;bufs[i].pool_entry scribbles all over the CPU's lowcore.
Resulting in a crash when those lowcore areas are used next (eg. on
the next machine-check interrupt).

Such a scenario would typically happen when the device is first set
online and its queues aren't allocated yet. An early IO error or certain
misconfigs (eg. mismatched transport mode, bad portno) then cause us to
error out from qeth_hardsetup_card() with card-&gt;qdio.in_q still being
NULL.

Fix it by checking the pointer for NULL before accessing it.

Note that we also have (rare) paths inside qeth_mpc_initialize() where
a configuration change can cause us to free the existing queues,
expecting that subsequent code will allocate them again. If we then
error out before that re-allocation happens, the same bug occurs.

Root-caused-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;</Note>
    </Notes>
    <CVE>CVE-2021-47369</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: macb: fix use after free on rmmod

plat_dev-&gt;dev-&gt;platform_data is released by platform_device_unregister(),
use of pclk and hclk is a use-after-free. Since device unregister won't
need a clk device we adjust the function call sequence to fix this issue.

[   31.261225] BUG: KASAN: use-after-free in macb_remove+0x77/0xc6 [macb_pci]
[   31.275563] Freed by task 306:
[   30.276782]  platform_device_release+0x25/0x80</Note>
    </Notes>
    <CVE>CVE-2021-47372</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

blktrace: Fix uaf in blk_trace access after removing by sysfs

There is an use-after-free problem triggered by following process:

      P1(sda)				P2(sdb)
			echo 0 &gt; /sys/block/sdb/trace/enable
			  blk_trace_remove_queue
			    synchronize_rcu
			    blk_trace_free
			      relay_close
rcu_read_lock
__blk_add_trace
  trace_note_tsk
  (Iterate running_trace_list)
			        relay_close_buf
				  relay_destroy_buf
				    kfree(buf)
    trace_note(sdb's bt)
      relay_reserve
        buf-&gt;offset &lt;- nullptr deference (use-after-free) !!!
rcu_read_unlock

[  502.714379] BUG: kernel NULL pointer dereference, address:
0000000000000010
[  502.715260] #PF: supervisor read access in kernel mode
[  502.715903] #PF: error_code(0x0000) - not-present page
[  502.716546] PGD 103984067 P4D 103984067 PUD 17592b067 PMD 0
[  502.717252] Oops: 0000 [#1] SMP
[  502.720308] RIP: 0010:trace_note.isra.0+0x86/0x360
[  502.732872] Call Trace:
[  502.733193]  __blk_add_trace.cold+0x137/0x1a3
[  502.733734]  blk_add_trace_rq+0x7b/0xd0
[  502.734207]  blk_add_trace_rq_issue+0x54/0xa0
[  502.734755]  blk_mq_start_request+0xde/0x1b0
[  502.735287]  scsi_queue_rq+0x528/0x1140
...
[  502.742704]  sg_new_write.isra.0+0x16e/0x3e0
[  502.747501]  sg_ioctl+0x466/0x1100

Reproduce method:
  ioctl(/dev/sda, BLKTRACESETUP, blk_user_trace_setup[buf_size=127])
  ioctl(/dev/sda, BLKTRACESTART)
  ioctl(/dev/sdb, BLKTRACESETUP, blk_user_trace_setup[buf_size=127])
  ioctl(/dev/sdb, BLKTRACESTART)

  echo 0 &gt; /sys/block/sdb/trace/enable &amp;
  // Add delay(mdelay/msleep) before kernel enters blk_trace_free()

  ioctl$SG_IO(/dev/sda, SG_IO, ...)
  // Enters trace_note_tsk() after blk_trace_free() returned
  // Use mdelay in rcu region rather than msleep(which may schedule out)

Remove blk_trace from running_list before calling blk_trace_free() by
sysfs if blk_trace is at Blktrace_running state.</Note>
    </Notes>
    <CVE>CVE-2021-47375</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: destroy cm id before destroy qp to avoid use after free

We should always destroy cm_id before destroy qp to avoid to get cma
event after qp was destroyed, which may lead to use after free.
In RDMA connection establishment error flow, don't destroy qp in cm
event handler.Just report cm_error to upper level, qp will be destroy
in nvme_rdma_alloc_queue() after destroy cm id.</Note>
    </Notes>
    <CVE>CVE-2021-47378</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

blk-cgroup: fix UAF by grabbing blkcg lock before destroying blkg pd

KASAN reports a use-after-free report when doing fuzz test:

[693354.104835] ==================================================================
[693354.105094] BUG: KASAN: use-after-free in bfq_io_set_weight_legacy+0xd3/0x160
[693354.105336] Read of size 4 at addr ffff888be0a35664 by task sh/1453338

[693354.105607] CPU: 41 PID: 1453338 Comm: sh Kdump: loaded Not tainted 4.18.0-147
[693354.105610] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 0.81 07/02/2018
[693354.105612] Call Trace:
[693354.105621]  dump_stack+0xf1/0x19b
[693354.105626]  ? show_regs_print_info+0x5/0x5
[693354.105634]  ? printk+0x9c/0xc3
[693354.105638]  ? cpumask_weight+0x1f/0x1f
[693354.105648]  print_address_description+0x70/0x360
[693354.105654]  kasan_report+0x1b2/0x330
[693354.105659]  ? bfq_io_set_weight_legacy+0xd3/0x160
[693354.105665]  ? bfq_io_set_weight_legacy+0xd3/0x160
[693354.105670]  bfq_io_set_weight_legacy+0xd3/0x160
[693354.105675]  ? bfq_cpd_init+0x20/0x20
[693354.105683]  cgroup_file_write+0x3aa/0x510
[693354.105693]  ? ___slab_alloc+0x507/0x540
[693354.105698]  ? cgroup_file_poll+0x60/0x60
[693354.105702]  ? 0xffffffff89600000
[693354.105708]  ? usercopy_abort+0x90/0x90
[693354.105716]  ? mutex_lock+0xef/0x180
[693354.105726]  kernfs_fop_write+0x1ab/0x280
[693354.105732]  ? cgroup_file_poll+0x60/0x60
[693354.105738]  vfs_write+0xe7/0x230
[693354.105744]  ksys_write+0xb0/0x140
[693354.105749]  ? __ia32_sys_read+0x50/0x50
[693354.105760]  do_syscall_64+0x112/0x370
[693354.105766]  ? syscall_return_slowpath+0x260/0x260
[693354.105772]  ? do_page_fault+0x9b/0x270
[693354.105779]  ? prepare_exit_to_usermode+0xf9/0x1a0
[693354.105784]  ? enter_from_user_mode+0x30/0x30
[693354.105793]  entry_SYSCALL_64_after_hwframe+0x65/0xca

[693354.105875] Allocated by task 1453337:
[693354.106001]  kasan_kmalloc+0xa0/0xd0
[693354.106006]  kmem_cache_alloc_node_trace+0x108/0x220
[693354.106010]  bfq_pd_alloc+0x96/0x120
[693354.106015]  blkcg_activate_policy+0x1b7/0x2b0
[693354.106020]  bfq_create_group_hierarchy+0x1e/0x80
[693354.106026]  bfq_init_queue+0x678/0x8c0
[693354.106031]  blk_mq_init_sched+0x1f8/0x460
[693354.106037]  elevator_switch_mq+0xe1/0x240
[693354.106041]  elevator_switch+0x25/0x40
[693354.106045]  elv_iosched_store+0x1a1/0x230
[693354.106049]  queue_attr_store+0x78/0xb0
[693354.106053]  kernfs_fop_write+0x1ab/0x280
[693354.106056]  vfs_write+0xe7/0x230
[693354.106060]  ksys_write+0xb0/0x140
[693354.106064]  do_syscall_64+0x112/0x370
[693354.106069]  entry_SYSCALL_64_after_hwframe+0x65/0xca

[693354.106114] Freed by task 1453336:
[693354.106225]  __kasan_slab_free+0x130/0x180
[693354.106229]  kfree+0x90/0x1b0
[693354.106233]  blkcg_deactivate_policy+0x12c/0x220
[693354.106238]  bfq_exit_queue+0xf5/0x110
[693354.106241]  blk_mq_exit_sched+0x104/0x130
[693354.106245]  __elevator_exit+0x45/0x60
[693354.106249]  elevator_switch_mq+0xd6/0x240
[693354.106253]  elevator_switch+0x25/0x40
[693354.106257]  elv_iosched_store+0x1a1/0x230
[693354.106261]  queue_attr_store+0x78/0xb0
[693354.106264]  kernfs_fop_write+0x1ab/0x280
[693354.106268]  vfs_write+0xe7/0x230
[693354.106271]  ksys_write+0xb0/0x140
[693354.106275]  do_syscall_64+0x112/0x370
[693354.106280]  entry_SYSCALL_64_after_hwframe+0x65/0xca

[693354.106329] The buggy address belongs to the object at ffff888be0a35580
                 which belongs to the cache kmalloc-1k of size 1024
[693354.106736] The buggy address is located 228 bytes inside of
                 1024-byte region [ffff888be0a35580, ffff888be0a35980)
[693354.107114] The buggy address belongs to the page:
[693354.107273] page:ffffea002f828c00 count:1 mapcount:0 mapping:ffff888107c17080 index:0x0 compound_mapcount: 0
[693354.107606] flags: 0x17ffffc0008100(slab|head)
[693354.107760] raw: 0017ffffc0008100 ffffea002fcbc808 ffffea0030bd3a08 ffff888107c17080
[693354.108020] r
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47379</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/qeth: fix deadlock during failing recovery

Commit 0b9902c1fcc5 ("s390/qeth: fix deadlock during recovery") removed
taking discipline_mutex inside qeth_do_reset(), fixing potential
deadlocks. An error path was missed though, that still takes
discipline_mutex and thus has the original deadlock potential.

Intermittent deadlocks were seen when a qeth channel path is configured
offline, causing a race between qeth_do_reset and ccwgroup_remove.
Call qeth_set_offline() directly in the qeth_do_reset() error case and
then a new variant of ccwgroup_set_offline(), without taking
discipline_mutex.</Note>
    </Notes>
    <CVE>CVE-2021-47382</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix out-of-bound vmalloc access in imageblit

This issue happens when a userspace program does an ioctl
FBIOPUT_VSCREENINFO passing the fb_var_screeninfo struct
containing only the fields xres, yres, and bits_per_pixel
with values.

If this struct is the same as the previous ioctl, the
vc_resize() detects it and doesn't call the resize_screen(),
leaving the fb_var_screeninfo incomplete. And this leads to
the updatescrollmode() calculates a wrong value to
fbcon_display-&gt;vrows, which makes the real_y() return a
wrong value of y, and that value, eventually, causes
the imageblit to access an out-of-bound address value.

To solve this issue I made the resize_screen() be called
even if the screen does not need any resizing, so it will
"fix and fill" the fb_var_screeninfo independently.</Note>
    </Notes>
    <CVE>CVE-2021-47383</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/cma: Ensure rdma_addr_cancel() happens before issuing more requests

The FSM can run in a circle allowing rdma_resolve_ip() to be called twice
on the same id_priv. While this cannot happen without going through the
work, it violates the invariant that the same address resolution
background request cannot be active twice.

       CPU 1                                  CPU 2

rdma_resolve_addr():
  RDMA_CM_IDLE -&gt; RDMA_CM_ADDR_QUERY
  rdma_resolve_ip(addr_handler)  #1

			 process_one_req(): for #1
                          addr_handler():
                            RDMA_CM_ADDR_QUERY -&gt; RDMA_CM_ADDR_BOUND
                            mutex_unlock(&amp;id_priv-&gt;handler_mutex);
                            [.. handler still running ..]

rdma_resolve_addr():
  RDMA_CM_ADDR_BOUND -&gt; RDMA_CM_ADDR_QUERY
  rdma_resolve_ip(addr_handler)
    !! two requests are now on the req_list

rdma_destroy_id():
 destroy_id_handler_unlock():
  _destroy_id():
   cma_cancel_operation():
    rdma_addr_cancel()

                          // process_one_req() self removes it
		          spin_lock_bh(&amp;lock);
                           cancel_delayed_work(&amp;req-&gt;work);
	                   if (!list_empty(&amp;req-&gt;list)) == true

      ! rdma_addr_cancel() returns after process_on_req #1 is done

   kfree(id_priv)

			 process_one_req(): for #2
                          addr_handler():
	                    mutex_lock(&amp;id_priv-&gt;handler_mutex);
                            !! Use after free on id_priv

rdma_addr_cancel() expects there to be one req on the list and only
cancels the first one. The self-removal behavior of the work only happens
after the handler has returned. This yields a situations where the
req_list can have two reqs for the same "handle" but rdma_addr_cancel()
only cancels the first one.

The second req remains active beyond rdma_destroy_id() and will
use-after-free id_priv once it inevitably triggers.

Fix this by remembering if the id_priv has called rdma_resolve_ip() and
always cancel before calling it again. This ensures the req_list never
gets more than one item in it and doesn't cost anything in the normal flow
that never uses this strange error path.</Note>
    </Notes>
    <CVE>CVE-2021-47391</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: break out if skb_header_pointer returns NULL in sctp_rcv_ootb

We should always check if skb_header_pointer's return is NULL before
using it, otherwise it may cause null-ptr-deref, as syzbot reported:

  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
  RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [inline]
  RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input.c:196
  Call Trace:
  &lt;IRQ&gt;
   sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109
   ip6_protocol_deliver_rcu+0x2e9/0x1ca0 net/ipv6/ip6_input.c:422
   ip6_input_finish+0x62/0x170 net/ipv6/ip6_input.c:463
   NF_HOOK include/linux/netfilter.h:307 [inline]
   NF_HOOK include/linux/netfilter.h:301 [inline]
   ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:472
   dst_input include/net/dst.h:460 [inline]
   ip6_rcv_finish net/ipv6/ip6_input.c:76 [inline]
   NF_HOOK include/linux/netfilter.h:307 [inline]
   NF_HOOK include/linux/netfilter.h:301 [inline]
   ipv6_rcv+0x28c/0x3c0 net/ipv6/ip6_input.c:297</Note>
    </Notes>
    <CVE>CVE-2021-47397</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: do not allow call hns3_nic_net_open repeatedly

hns3_nic_net_open() is not allowed to called repeatly, but there
is no checking for this. When doing device reset and setup tc
concurrently, there is a small oppotunity to call hns3_nic_net_open
repeatedly, and cause kernel bug by calling napi_enable twice.

The calltrace information is like below:
[ 3078.222780] ------------[ cut here ]------------
[ 3078.230255] kernel BUG at net/core/dev.c:6991!
[ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 3078.243431] Modules linked in: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O)
[ 3078.258880] CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G           O      5.14.0-rc4+ #1
[ 3078.269102] Hardware name:  , BIOS KpxxxFPGA 1P B600 V181 08/12/2021
[ 3078.276801] Workqueue: hclge hclge_service_task [hclge]
[ 3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)
[ 3078.296168] pc : napi_enable+0x80/0x84
tc qdisc sho[w  3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3]

[ 3078.314771] sp : ffff8000108abb20
[ 3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27: ffff0820a8490300
[ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 0000000000000000
[ 3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880
[ 3078.349018] x20: 0000000000000000 x19: ffff08209cd76900 x18: 0000000000000000
[ 3078.358620] x17: 0000000000000000 x16: ffffc816e1727a50 x15: 0000ffff8f4ff930
[ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12: 0000259e9dbeb6b4
[ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8
[ 3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344
[ 3078.396356] x5 : 0000000000000140 x4 : 0000000000000003 x3 : ffff08209cd76938
[ 3078.405365] x2 : 0000000000000000 x1 : 0000000000000010 x0 : ffff0820abfe38a0
[ 3078.414657] Call trace:
[ 3078.418517]  napi_enable+0x80/0x84
[ 3078.424626]  hns3_reset_notify_up_enet+0x78/0xd0 [hns3]
[ 3078.433469]  hns3_reset_notify+0x64/0x80 [hns3]
[ 3078.441430]  hclge_notify_client+0x68/0xb0 [hclge]
[ 3078.450511]  hclge_reset_rebuild+0x524/0x884 [hclge]
[ 3078.458879]  hclge_reset_service_task+0x3c4/0x680 [hclge]
[ 3078.467470]  hclge_service_task+0xb0/0xb54 [hclge]
[ 3078.475675]  process_one_work+0x1dc/0x48c
[ 3078.481888]  worker_thread+0x15c/0x464
[ 3078.487104]  kthread+0x160/0x170
[ 3078.492479]  ret_from_fork+0x10/0x18
[ 3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000)
[ 3078.506889] ---[ end trace 8ebe0340a1b0fb44 ]---

Once hns3_nic_net_open() is excute success, the flag
HNS3_NIC_STATE_DOWN will be cleared. So add checking for this
flag, directly return when HNS3_NIC_STATE_DOWN is no set.</Note>
    </Notes>
    <CVE>CVE-2021-47400</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 stack information leak

The tty driver name is used also after registering the driver and must
specifically not be allocated on the stack to avoid leaking information
to user space (or triggering an oops).

Drivers should not try to encode topology information in the tty device
name but this one snuck in through staging without anyone noticing and
another driver has since copied this malpractice.

Fixing the ABI is a separate issue, but this at least plugs the security
hole.</Note>
    </Notes>
    <CVE>CVE-2021-47401</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: betop: fix slab-out-of-bounds Write in betop_probe

Syzbot reported slab-out-of-bounds Write bug in hid-betopff driver.
The problem is the driver assumes the device must have an input report but
some malicious devices violate this assumption.

So this patch checks hid_device's input is non empty before it's been used.</Note>
    </Notes>
    <CVE>CVE-2021-47404</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Handle SRCU initialization failure during page track init

Check the return of init_srcu_struct(), which can fail due to OOM, when
initializing the page track mechanism.  Lack of checking leads to a NULL
pointer deref found by a modified syzkaller.

[Move the call towards the beginning of kvm_arch_init_vm. - Paolo]</Note>
    </Notes>
    <CVE>CVE-2021-47407</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dwc2: check return value after calling platform_get_resource()

It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.</Note>
    </Notes>
    <CVE>CVE-2021-47409</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net_sched: fix NULL deref in fifo_set_limit()

syzbot reported another NULL deref in fifo_set_limit() [1]

I could repro the issue with :

unshare -n
tc qd add dev lo root handle 1:0 tbf limit 200000 burst 70000 rate 100Mbit
tc qd replace dev lo parent 1:0 pfifo_fast
tc qd change dev lo root handle 1:0 tbf limit 300000 burst 70000 rate 100Mbit

pfifo_fast does not have a change() operation.
Make fifo_set_limit() more robust about this.

[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 1cf99067 P4D 1cf99067 PUD 7ca49067 PMD 0
Oops: 0010 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 14443 Comm: syz-executor959 Not tainted 5.15.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:0x0
Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
RSP: 0018:ffffc9000e2f7310 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffffffff8d6ecc00 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff888024c27910 RDI: ffff888071e34000
RBP: ffff888071e34000 R08: 0000000000000001 R09: ffffffff8fcfb947
R10: 0000000000000001 R11: 0000000000000000 R12: ffff888024c27910
R13: ffff888071e34018 R14: 0000000000000000 R15: ffff88801ef74800
FS:  00007f321d897700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 00000000722c3000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 fifo_set_limit net/sched/sch_fifo.c:242 [inline]
 fifo_set_limit+0x198/0x210 net/sched/sch_fifo.c:227
 tbf_change+0x6ec/0x16d0 net/sched/sch_tbf.c:418
 qdisc_change net/sched/sch_api.c:1332 [inline]
 tc_modify_qdisc+0xd9a/0x1a60 net/sched/sch_api.c:1634
 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5572
 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504
 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
 netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340
 netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929
 sock_sendmsg_nosec net/socket.c:704 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:724
 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492
 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</Note>
    </Notes>
    <CVE>CVE-2021-47418</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/debugfs: fix file release memory leak

When using single_open() for opening, single_release() should be
called, otherwise the 'op' allocated in single_open() will be leaked.</Note>
    </Notes>
    <CVE>CVE-2021-47423</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 freeing of uninitialized misc IRQ vector

When VSI set up failed in i40e_probe() as part of PF switch set up
driver was trying to free misc IRQ vectors in
i40e_clear_interrupt_scheme and produced a kernel Oops:

   Trying to free already-free IRQ 266
   WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300
   Workqueue: events work_for_cpu_fn
   RIP: 0010:__free_irq+0x9a/0x300
   Call Trace:
   ? synchronize_irq+0x3a/0xa0
   free_irq+0x2e/0x60
   i40e_clear_interrupt_scheme+0x53/0x190 [i40e]
   i40e_probe.part.108+0x134b/0x1a40 [i40e]
   ? kmem_cache_alloc+0x158/0x1c0
   ? acpi_ut_update_ref_count.part.1+0x8e/0x345
   ? acpi_ut_update_object_reference+0x15e/0x1e2
   ? strstr+0x21/0x70
   ? irq_get_irq_data+0xa/0x20
   ? mp_check_pin_attr+0x13/0xc0
   ? irq_get_irq_data+0xa/0x20
   ? mp_map_pin_to_irq+0xd3/0x2f0
   ? acpi_register_gsi_ioapic+0x93/0x170
   ? pci_conf1_read+0xa4/0x100
   ? pci_bus_read_config_word+0x49/0x70
   ? do_pci_enable_device+0xcc/0x100
   local_pci_probe+0x41/0x90
   work_for_cpu_fn+0x16/0x20
   process_one_work+0x1a7/0x360
   worker_thread+0x1cf/0x390
   ? create_worker+0x1a0/0x1a0
   kthread+0x112/0x130
   ? kthread_flush_work_fn+0x10/0x10
   ret_from_fork+0x1f/0x40

The problem is that at that point misc IRQ vectors
were not allocated yet and we get a call trace
that driver is trying to free already free IRQ vectors.

Add a check in i40e_clear_interrupt_scheme for __I40E_MISC_IRQ_REQUESTED
PF state before calling i40e_free_misc_vector. This state is set only if
misc IRQ vectors were properly initialized.</Note>
    </Notes>
    <CVE>CVE-2021-47424</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 gart.bo pin_count leak

gmc_v{9,10}_0_gart_disable() isn't called matched with
correspoding gart_enbale function in SRIOV case. This will
lead to gart.bo pin_count leak on driver unload.</Note>
    </Notes>
    <CVE>CVE-2021-47431</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 command ring pointer corruption while aborting a command

The command ring pointer is located at [6:63] bits of the command
ring control register (CRCR). All the control bits like command stop,
abort are located at [0:3] bits. While aborting a command, we read the
CRCR and set the abort bit and write to the CRCR. The read will always
give command ring pointer as all zeros. So we essentially write only
the control bits. Since we split the 64 bit write into two 32 bit writes,
there is a possibility of xHC command ring stopped before the upper
dword (all zeros) is written. If that happens, xHC updates the upper
dword of its internal command ring pointer with all zeros. Next time,
when the command ring is restarted, we see xHC memory access failures.
Fix this issue by only writing to the lower dword of CRCR where all
control bits are located.</Note>
    </Notes>
    <CVE>CVE-2021-47434</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix mempool NULL pointer race when completing IO

dm_io_dec_pending() calls end_io_acct() first and will then dec md
in-flight pending count. But if a task is swapping DM table at same
time this can result in a crash due to mempool-&gt;elements being NULL:

task1                             task2
do_resume
 -&gt;do_suspend
  -&gt;dm_wait_for_completion
                                  bio_endio
				   -&gt;clone_endio
				    -&gt;dm_io_dec_pending
				     -&gt;end_io_acct
				      -&gt;wakeup task1
 -&gt;dm_swap_table
  -&gt;__bind
   -&gt;__bind_mempools
    -&gt;bioset_exit
     -&gt;mempool_exit
                                     -&gt;free_io

[ 67.330330] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000000
......
[ 67.330494] pstate: 80400085 (Nzcv daIf +PAN -UAO)
[ 67.330510] pc : mempool_free+0x70/0xa0
[ 67.330515] lr : mempool_free+0x4c/0xa0
[ 67.330520] sp : ffffff8008013b20
[ 67.330524] x29: ffffff8008013b20 x28: 0000000000000004
[ 67.330530] x27: ffffffa8c2ff40a0 x26: 00000000ffff1cc8
[ 67.330535] x25: 0000000000000000 x24: ffffffdada34c800
[ 67.330541] x23: 0000000000000000 x22: ffffffdada34c800
[ 67.330547] x21: 00000000ffff1cc8 x20: ffffffd9a1304d80
[ 67.330552] x19: ffffffdada34c970 x18: 000000b312625d9c
[ 67.330558] x17: 00000000002dcfbf x16: 00000000000006dd
[ 67.330563] x15: 000000000093b41e x14: 0000000000000010
[ 67.330569] x13: 0000000000007f7a x12: 0000000034155555
[ 67.330574] x11: 0000000000000001 x10: 0000000000000001
[ 67.330579] x9 : 0000000000000000 x8 : 0000000000000000
[ 67.330585] x7 : 0000000000000000 x6 : ffffff80148b5c1a
[ 67.330590] x5 : ffffff8008013ae0 x4 : 0000000000000001
[ 67.330596] x3 : ffffff80080139c8 x2 : ffffff801083bab8
[ 67.330601] x1 : 0000000000000000 x0 : ffffffdada34c970
[ 67.330609] Call trace:
[ 67.330616] mempool_free+0x70/0xa0
[ 67.330627] bio_put+0xf8/0x110
[ 67.330638] dec_pending+0x13c/0x230
[ 67.330644] clone_endio+0x90/0x180
[ 67.330649] bio_endio+0x198/0x1b8
[ 67.330655] dec_pending+0x190/0x230
[ 67.330660] clone_endio+0x90/0x180
[ 67.330665] bio_endio+0x198/0x1b8
[ 67.330673] blk_update_request+0x214/0x428
[ 67.330683] scsi_end_request+0x2c/0x300
[ 67.330688] scsi_io_completion+0xa0/0x710
[ 67.330695] scsi_finish_command+0xd8/0x110
[ 67.330700] scsi_softirq_done+0x114/0x148
[ 67.330708] blk_done_softirq+0x74/0xd0
[ 67.330716] __do_softirq+0x18c/0x374
[ 67.330724] irq_exit+0xb4/0xb8
[ 67.330732] __handle_domain_irq+0x84/0xc0
[ 67.330737] gic_handle_irq+0x148/0x1b0
[ 67.330744] el1_irq+0xe8/0x190
[ 67.330753] lpm_cpuidle_enter+0x4f8/0x538
[ 67.330759] cpuidle_enter_state+0x1fc/0x398
[ 67.330764] cpuidle_enter+0x18/0x20
[ 67.330772] do_idle+0x1b4/0x290
[ 67.330778] cpu_startup_entry+0x20/0x28
[ 67.330786] secondary_start_kernel+0x160/0x170

Fix this by:
1) Establishing pointers to 'struct dm_io' members in
dm_io_dec_pending() so that they may be passed into end_io_acct()
_after_ free_io() is called.
2) Moving end_io_acct() after free_io().</Note>
    </Notes>
    <CVE>CVE-2021-47435</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: musb: dsps: Fix the probe error path

Commit 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after
initializing musb") has inverted the calls to
dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev() without
updating correctly the error path. dsps_create_musb_pdev() allocates and
registers a new platform device which must be unregistered and freed
with platform_device_unregister(), and this is missing upon
dsps_setup_optional_vbus_irq() error.

While on the master branch it seems not to trigger any issue, I observed
a kernel crash because of a NULL pointer dereference with a v5.10.70
stable kernel where the patch mentioned above was backported. With this
kernel version, -EPROBE_DEFER is returned the first time
dsps_setup_optional_vbus_irq() is called which triggers the probe to
error out without unregistering the platform device. Unfortunately, on
the Beagle Bone Black Wireless, the platform device still living in the
system is being used by the USB Ethernet gadget driver, which during the
boot phase triggers the crash.

My limited knowledge of the musb world prevents me to revert this commit
which was sent to silence a robot warning which, as far as I understand,
does not make sense. The goal of this patch was to prevent an IRQ to
fire before the platform device being registered. I think this cannot
ever happen due to the fact that enabling the interrupts is done by the
-&gt;enable() callback of the platform musb device, and this platform
device must be already registered in order for the core or any other
user to use this callback.

Hence, I decided to fix the error path, which might prevent future
errors on mainline kernels while also fixing older ones.</Note>
    </Notes>
    <CVE>CVE-2021-47436</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix null pointer dereference on pointer edp

The initialization of pointer dev dereferences pointer edp before
edp is null checked, so there is a potential null pointer deference
issue. Fix this by only dereferencing edp after edp has been null
checked.

Addresses-Coverity: ("Dereference before null check")</Note>
    </Notes>
    <CVE>CVE-2021-47445</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

can: peak_pci: peak_pci_remove(): fix UAF

When remove the module peek_pci, referencing 'chan' again after
releasing 'dev' will cause UAF.

Fix this by releasing 'dev' later.

The following log reveals it:

[   35.961814 ] BUG: KASAN: use-after-free in peak_pci_remove+0x16f/0x270 [peak_pci]
[   35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537
[   35.965513 ] Call Trace:
[   35.965718 ]  dump_stack_lvl+0xa8/0xd1
[   35.966028 ]  print_address_description+0x87/0x3b0
[   35.966420 ]  kasan_report+0x172/0x1c0
[   35.966725 ]  ? peak_pci_remove+0x16f/0x270 [peak_pci]
[   35.967137 ]  ? trace_irq_enable_rcuidle+0x10/0x170
[   35.967529 ]  ? peak_pci_remove+0x16f/0x270 [peak_pci]
[   35.967945 ]  __asan_report_load8_noabort+0x14/0x20
[   35.968346 ]  peak_pci_remove+0x16f/0x270 [peak_pci]
[   35.968752 ]  pci_device_remove+0xa9/0x250</Note>
    </Notes>
    <CVE>CVE-2021-47456</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mount fails with buffer overflow in strlen

Starting with kernel 5.11 built with CONFIG_FORTIFY_SOURCE mouting an
ocfs2 filesystem with either o2cb or pcmk cluster stack fails with the
trace below.  Problem seems to be that strings for cluster stack and
cluster name are not guaranteed to be null terminated in the disk
representation, while strlcpy assumes that the source string is always
null terminated.  This causes a read outside of the source string
triggering the buffer overflow detection.

  detected buffer overflow in strlen
  ------------[ cut here ]------------
  kernel BUG at lib/string.c:1149!
  invalid opcode: 0000 [#1] SMP PTI
  CPU: 1 PID: 910 Comm: mount.ocfs2 Not tainted 5.14.0-1-amd64 #1
    Debian 5.14.6-2
  RIP: 0010:fortify_panic+0xf/0x11
  ...
  Call Trace:
   ocfs2_initialize_super.isra.0.cold+0xc/0x18 [ocfs2]
   ocfs2_fill_super+0x359/0x19b0 [ocfs2]
   mount_bdev+0x185/0x1b0
   legacy_get_tree+0x27/0x40
   vfs_get_tree+0x25/0xb0
   path_mount+0x454/0xa20
   __x64_sys_mount+0x103/0x140
   do_syscall_64+0x3b/0xc0
   entry_SYSCALL_64_after_hwframe+0x44/0xae</Note>
    </Notes>
    <CVE>CVE-2021-47458</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 data corruption after conversion from inline format

Commit 6dbf7bb55598 ("fs: Don't invalidate page buffers in
block_write_full_page()") uncovered a latent bug in ocfs2 conversion
from inline inode format to a normal inode format.

The code in ocfs2_convert_inline_data_to_extents() attempts to zero out
the whole cluster allocated for file data by grabbing, zeroing, and
dirtying all pages covering this cluster.  However these pages are
beyond i_size, thus writeback code generally ignores these dirty pages
and no blocks were ever actually zeroed on the disk.

This oversight was fixed by commit 693c241a5f6a ("ocfs2: No need to zero
pages past i_size.") for standard ocfs2 write path, inline conversion
path was apparently forgotten; the commit log also has a reasoning why
the zeroing actually is not needed.

After commit 6dbf7bb55598, things became worse as writeback code stopped
invalidating buffers on pages beyond i_size and thus these pages end up
with clean PageDirty bit but with buffers attached to these pages being
still dirty.  So when a file is converted from inline format, then
writeback triggers, and then the file is grown so that these pages
become valid, the invalid dirtiness state is preserved,
mark_buffer_dirty() does nothing on these pages (buffers are already
dirty) but page is never written back because it is clean.  So data
written to these pages is lost once pages are reclaimed.

Simple reproducer for the problem is:

  xfs_io -f -c "pwrite 0 2000" -c "pwrite 2000 2000" -c "fsync" \
    -c "pwrite 4000 2000" ocfs2_file

After unmounting and mounting the fs again, you can observe that end of
'ocfs2_file' has lost its contents.

Fix the problem by not doing the pointless zeroing during conversion
from inline format similarly as in the standard write path.

[akpm@linux-foundation.org: fix whitespace, per Joseph]</Note>
    </Notes>
    <CVE>CVE-2021-47460</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-2021-47469</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-2021-47472</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 a memory leak in an error path of qla2x00_process_els()

Commit 8c0eb596baa5 ("[SCSI] qla2xxx: Fix a memory leak in an error path of
qla2x00_process_els()"), intended to change:

        bsg_job-&gt;request-&gt;msgcode == FC_BSG_HST_ELS_NOLOGIN


        bsg_job-&gt;request-&gt;msgcode != FC_BSG_RPT_ELS

but changed it to:

        bsg_job-&gt;request-&gt;msgcode == FC_BSG_RPT_ELS

instead.

Change the == to a != to avoid leaking the fcport structure or freeing
unallocated memory.</Note>
    </Notes>
    <CVE>CVE-2021-47473</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

isofs: Fix out of bound access for corrupted isofs image

When isofs image is suitably corrupted isofs_read_inode() can read data
beyond the end of buffer. Sanity-check the directory entry length before
using it.</Note>
    </Notes>
    <CVE>CVE-2021-47478</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: core: Put LLD module refcnt after SCSI device is released

SCSI host release is triggered when SCSI device is freed. We have to make
sure that the low-level device driver module won't be unloaded before SCSI
host instance is released because shost-&gt;hostt is required in the release
handler.

Make sure to put LLD module refcnt after SCSI device is released.

Fixes a kernel panic of 'BUG: unable to handle page fault for address'
reported by Changhui and Yi.</Note>
    </Notes>
    <CVE>CVE-2021-47480</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

regmap: Fix possible double-free in regcache_rbtree_exit()

In regcache_rbtree_insert_to_block(), when 'present' realloc failed,
the 'blk' which is supposed to assign to 'rbnode-&gt;block' will be freed,
so 'rbnode-&gt;block' points a freed memory, in the error handling path of
regcache_rbtree_init(), 'rbnode-&gt;block' will be freed again in
regcache_rbtree_exit(), KASAN will report double-free as follows:

BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390
Call Trace:
 slab_free_freelist_hook+0x10d/0x240
 kfree+0xce/0x390
 regcache_rbtree_exit+0x15d/0x1a0
 regcache_rbtree_init+0x224/0x2c0
 regcache_init+0x88d/0x1310
 __regmap_init+0x3151/0x4a80
 __devm_regmap_init+0x7d/0x100
 madera_spi_probe+0x10f/0x333 [madera_spi]
 spi_probe+0x183/0x210
 really_probe+0x285/0xc30

To fix this, moving up the assignment of rbnode-&gt;block to immediately after
the reallocation has succeeded so that the data structure stays valid even
if the second reallocation fails.</Note>
    </Notes>
    <CVE>CVE-2021-47483</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/qib: Protect from buffer overflow in struct qib_user_sdma_pkt fields

Overflowing either addrlimit or bytes_togo can allow userspace to trigger
a buffer overflow of kernel memory. Check for overflows in all the places
doing math on user controlled buffers.</Note>
    </Notes>
    <CVE>CVE-2021-47485</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usbnet: sanity check for maxpacket

maxpacket of 0 makes no sense and oopses as we need to divide
by it. Give up.

V2: fixed typo in log and stylistic issues</Note>
    </Notes>
    <CVE>CVE-2021-47495</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/tls: Fix flipped sign in tls_err_abort() calls

sk-&gt;sk_err appears to expect a positive value, a convention that ktls
doesn't always follow and that leads to memory corruption in other code.
For instance,

    [kworker]
    tls_encrypt_done(..., err=&lt;negative error from crypto request&gt;)
      tls_err_abort(.., err)
        sk-&gt;sk_err = err;

    [task]
    splice_from_pipe_feed
      ...
        tls_sw_do_sendpage
          if (sk-&gt;sk_err) {
            ret = -sk-&gt;sk_err;  // ret is positive

    splice_from_pipe_feed (continued)
      ret = actor(...)  // ret is still positive and interpreted as bytes
                        // written, resulting in underflow of buf-&gt;len and
                        // sd-&gt;len, leading to huge buf-&gt;offset and bogus
                        // addresses computed in later calls to actor()

Fix all tls_err_abort() callers to pass a negative error code
consistently and centralize the error-prone sign flip there, throwing in
a warning to catch future misuse and uninlining the function so it
really does only warn once.</Note>
    </Notes>
    <CVE>CVE-2021-47496</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells

If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic

 *p &amp;= GENMASK((cell-&gt;nbits%BITS_PER_BYTE) - 1, 0);

will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we
subtract one from that making a large number that is then shifted more than the
number of bits that fit into an unsigned long.

UBSAN reports this problem:

 UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8
 shift exponent 64 is too large for 64-bit type 'unsigned long'
 CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9
 Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
 Workqueue: events_unbound deferred_probe_work_func
 Call trace:
  dump_backtrace+0x0/0x170
  show_stack+0x24/0x30
  dump_stack_lvl+0x64/0x7c
  dump_stack+0x18/0x38
  ubsan_epilogue+0x10/0x54
  __ubsan_handle_shift_out_of_bounds+0x180/0x194
  __nvmem_cell_read+0x1ec/0x21c
  nvmem_cell_read+0x58/0x94
  nvmem_cell_read_variable_common+0x4c/0xb0
  nvmem_cell_read_variable_le_u32+0x40/0x100
  a6xx_gpu_init+0x170/0x2f4
  adreno_bind+0x174/0x284
  component_bind_all+0xf0/0x264
  msm_drm_bind+0x1d8/0x7a0
  try_to_bring_up_master+0x164/0x1ac
  __component_add+0xbc/0x13c
  component_add+0x20/0x2c
  dp_display_probe+0x340/0x384
  platform_probe+0xc0/0x100
  really_probe+0x110/0x304
  __driver_probe_device+0xb8/0x120
  driver_probe_device+0x4c/0xfc
  __device_attach_driver+0xb0/0x128
  bus_for_each_drv+0x90/0xdc
  __device_attach+0xc8/0x174
  device_initial_probe+0x20/0x2c
  bus_probe_device+0x40/0xa4
  deferred_probe_work_func+0x7c/0xb8
  process_one_work+0x128/0x21c
  process_scheduled_works+0x40/0x54
  worker_thread+0x1ec/0x2a8
  kthread+0x138/0x158
  ret_from_fork+0x10/0x20

Fix it by making sure there are any bits to mask out.</Note>
    </Notes>
    <CVE>CVE-2021-47497</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 rq: don't queue request to blk-mq during DM suspend

DM uses blk-mq's quiesce/unquiesce to stop/start device mapper queue.

But blk-mq's unquiesce may come from outside events, such as elevator
switch, updating nr_requests or others, and request may come during
suspend, so simply ask for blk-mq to requeue it.

Fixes one kernel panic issue when running updating nr_requests and
dm-mpath suspend/resume stress test.</Note>
    </Notes>
    <CVE>CVE-2021-47498</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iio: mma8452: Fix trigger reference couting

The mma8452 driver directly assigns a trigger to the struct iio_dev. The
IIO core when done using this trigger will call `iio_trigger_put()` to drop
the reference count by 1.

Without the matching `iio_trigger_get()` in the driver the reference count
can reach 0 too early, the trigger gets freed while still in use and a
use-after-free occurs.

Fix this by getting a reference to the trigger before assigning it to the
IIO device.</Note>
    </Notes>
    <CVE>CVE-2021-47500</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use-after-free due to delegation race

A delegation break could arrive as soon as we've called vfs_setlease.  A
delegation break runs a callback which immediately (in
nfsd4_cb_recall_prepare) adds the delegation to del_recall_lru.  If we
then exit nfs4_set_delegation without hashing the delegation, it will be
freed as soon as the callback is done with it, without ever being
removed from del_recall_lru.

Symptoms show up later as use-after-free or list corruption warnings,
usually in the laundromat thread.

I suspect aba2072f4523 "nfsd: grant read delegations to clients holding
writes" made this bug easier to hit, but I looked as far back as v3.0
and it looks to me it already had the same problem.  So I'm not sure
where the bug was introduced; it may have been there from the beginning.</Note>
    </Notes>
    <CVE>CVE-2021-47506</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pcm: oss: Limit the period size to 16MB

Set the practical limit to the period size (the fragment shift in OSS)
instead of a full 31bit; a too large value could lead to the exhaust
of memory as we allocate temporary buffers of the period size, too.

As of this patch, we set to 16MB limit, which should cover all use
cases.</Note>
    </Notes>
    <CVE>CVE-2021-47509</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pcm: oss: Fix negative period/buffer sizes

The period size calculation in OSS layer may receive a negative value
as an error, but the code there assumes only the positive values and
handle them with size_t.  Due to that, a too big value may be passed
to the lower layers.

This patch changes the code to handle with ssize_t and adds the proper
error checks appropriately.</Note>
    </Notes>
    <CVE>CVE-2021-47511</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential NULL pointer deref in nfc_genl_dump_ses_done

The done() netlink callback nfc_genl_dump_ses_done() should check if
received argument is non-NULL, because its allocation could fail earlier
in dumpit() (nfc_genl_dump_ses()).</Note>
    </Notes>
    <CVE>CVE-2021-47518</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pch_can: pch_can_rx_normal: fix use after free

After calling netif_receive_skb(skb), dereferencing skb is unsafe.
Especially, the can_frame cf which aliases skb memory is dereferenced
just after the call netif_receive_skb(skb).

Reordering the lines solves the issue.</Note>
    </Notes>
    <CVE>CVE-2021-47520</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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:

IB/hfi1: Fix leak of rcvhdrtail_dummy_kvaddr

This buffer is currently allocated in hfi1_init():

	if (reinit)
		ret = init_after_reset(dd);
	else
		ret = loadtime_init(dd);
	if (ret)
		goto done;

	/* allocate dummy tail memory for all receive contexts */
	dd-&gt;rcvhdrtail_dummy_kvaddr = dma_alloc_coherent(&amp;dd-&gt;pcidev-&gt;dev,
							 sizeof(u64),
							 &amp;dd-&gt;rcvhdrtail_dummy_dma,
							 GFP_KERNEL);

	if (!dd-&gt;rcvhdrtail_dummy_kvaddr) {
		dd_dev_err(dd, "cannot allocate dummy tail memory\n");
		ret = -ENOMEM;
		goto done;
	}

The reinit triggered path will overwrite the old allocation and leak it.

Fix by moving the allocation to hfi1_alloc_devdata() and the deallocation
to hfi1_free_devdata().</Note>
    </Notes>
    <CVE>CVE-2021-47523</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/mlx4_en: Fix an use-after-free bug in mlx4_en_try_alloc_resources()

In mlx4_en_try_alloc_resources(), mlx4_en_copy_priv() is called and
tmp-&gt;tx_cq will be freed on the error path of mlx4_en_copy_priv().
After that mlx4_en_alloc_resources() is called and there is a dereference
of &amp;tmp-&gt;tx_cq[t][i] in mlx4_en_alloc_resources(), which could lead to
a use after free problem on failure of mlx4_en_copy_priv().

Fix this bug by adding a check of mlx4_en_copy_priv()

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_MLX4_EN=m show no new warnings,
and our static analyzer no longer warns about this code.</Note>
    </Notes>
    <CVE>CVE-2021-47541</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tcp: fix page frag corruption on page fault

Steffen reported a TCP stream corruption for HTTP requests
served by the apache web-server using a cifs mount-point
and memory mapping the relevant file.

The root cause is quite similar to the one addressed by
commit 20eb4f29b602 ("net: fix sk_page_frag() recursion from
memory reclaim"). Here the nested access to the task page frag
is caused by a page fault on the (mmapped) user-space memory
buffer coming from the cifs file.

The page fault handler performs an smb transaction on a different
socket, inside the same process context. Since sk-&gt;sk_allaction
for such socket does not prevent the usage for the task_frag,
the nested allocation modify "under the hood" the page frag
in use by the outer sendmsg call, corrupting the stream.

The overall relevant stack trace looks like the following:

httpd 78268 [001] 3461630.850950:      probe:tcp_sendmsg_locked:
        ffffffff91461d91 tcp_sendmsg_locked+0x1
        ffffffff91462b57 tcp_sendmsg+0x27
        ffffffff9139814e sock_sendmsg+0x3e
        ffffffffc06dfe1d smb_send_kvec+0x28
        [...]
        ffffffffc06cfaf8 cifs_readpages+0x213
        ffffffff90e83c4b read_pages+0x6b
        ffffffff90e83f31 __do_page_cache_readahead+0x1c1
        ffffffff90e79e98 filemap_fault+0x788
        ffffffff90eb0458 __do_fault+0x38
        ffffffff90eb5280 do_fault+0x1a0
        ffffffff90eb7c84 __handle_mm_fault+0x4d4
        ffffffff90eb8093 handle_mm_fault+0xc3
        ffffffff90c74f6d __do_page_fault+0x1ed
        ffffffff90c75277 do_page_fault+0x37
        ffffffff9160111e page_fault+0x1e
        ffffffff9109e7b5 copyin+0x25
        ffffffff9109eb40 _copy_from_iter_full+0xe0
        ffffffff91462370 tcp_sendmsg_locked+0x5e0
        ffffffff91462370 tcp_sendmsg_locked+0x5e0
        ffffffff91462b57 tcp_sendmsg+0x27
        ffffffff9139815c sock_sendmsg+0x4c
        ffffffff913981f7 sock_write_iter+0x97
        ffffffff90f2cc56 do_iter_readv_writev+0x156
        ffffffff90f2dff0 do_iter_write+0x80
        ffffffff90f2e1c3 vfs_writev+0xa3
        ffffffff90f2e27c do_writev+0x5c
        ffffffff90c042bb do_syscall_64+0x5b
        ffffffff916000ad entry_SYSCALL_64_after_hwframe+0x65

The cifs filesystem rightfully sets sk_allocations to GFP_NOFS,
we can avoid the nesting using the sk page frag for allocation
lacking the __GFP_FS flag. Do not define an additional mm-helper
for that, as this is strictly tied to the sk page frag usage.

v1 -&gt; v2:
 - use a stricted sk_page_frag() check instead of reordering the
   code (Eric)</Note>
    </Notes>
    <CVE>CVE-2021-47544</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: tulip: de4x5: fix the problem that the array 'lp-&gt;phy[8]' may be out of bound

In line 5001, if all id in the array 'lp-&gt;phy[8]' is not 0, when the
'for' end, the 'k' is 8.

At this time, the array 'lp-&gt;phy[8]' may be out of bound.</Note>
    </Notes>
    <CVE>CVE-2021-47547</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port()

The if statement:
  if (port &gt;= DSAF_GE_NUM)
        return;

limits the value of port less than DSAF_GE_NUM (i.e., 8).
However, if the value of port is 6 or 7, an array overflow could occur:
  port_rst_off = dsaf_dev-&gt;mac_cb[port]-&gt;port_rst_off;

because the length of dsaf_dev-&gt;mac_cb is DSAF_MAX_PORT_NUM (i.e., 6).

To fix this possible array overflow, we first check port and if it is
greater than or equal to DSAF_MAX_PORT_NUM, the function returns.</Note>
    </Notes>
    <CVE>CVE-2021-47548</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: mpt3sas: Fix kernel panic during drive powercycle test

While looping over shost's sdev list it is possible that one
of the drives is getting removed and its sas_target object is
freed but its sdev object remains intact.

Consequently, a kernel panic can occur while the driver is trying to access
the sas_address field of sas_target object without also checking the
sas_target object for NULL.</Note>
    </Notes>
    <CVE>CVE-2021-47565</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

proc/vmcore: fix clearing user buffer by properly using clear_user()

To clear a user buffer we cannot simply use memset, we have to use
clear_user().  With a virtio-mem device that registers a vmcore_cb and
has some logically unplugged memory inside an added Linux memory block,
I can easily trigger a BUG by copying the vmcore via "cp":

  systemd[1]: Starting Kdump Vmcore Save Service...
  kdump[420]: Kdump is using the default log level(3).
  kdump[453]: saving to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/
  kdump[458]: saving vmcore-dmesg.txt to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/
  kdump[465]: saving vmcore-dmesg.txt complete
  kdump[467]: saving vmcore
  BUG: unable to handle page fault for address: 00007f2374e01000
  #PF: supervisor write access in kernel mode
  #PF: error_code(0x0003) - permissions violation
  PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867
  Oops: 0003 [#1] PREEMPT SMP NOPTI
  CPU: 0 PID: 468 Comm: cp Not tainted 5.15.0+ #6
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 04/01/2014
  RIP: 0010:read_from_oldmem.part.0.cold+0x1d/0x86
  Code: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 &lt;49&gt; c7 45 00 00 00 00 00 49 c7 44 05 f8 00 00 00 00 48 83 e7 f81
  RSP: 0018:ffffc9000073be08 EFLAGS: 00010212
  RAX: 0000000000001000 RBX: 00000000002fd000 RCX: 00007f2374e01000
  RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00007f2374e01008
  RBP: 0000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50
  R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000
  R13: 00007f2374e01000 R14: 0000000000000000 R15: ffff88807bd421e8
  FS:  00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0
  Call Trace:
   read_vmcore+0x236/0x2c0
   proc_reg_read+0x55/0xa0
   vfs_read+0x95/0x190
   ksys_read+0x4f/0xc0
   do_syscall_64+0x3b/0x90
   entry_SYSCALL_64_after_hwframe+0x44/0xae

Some x86-64 CPUs have a CPU feature called "Supervisor Mode Access
Prevention (SMAP)", which is used to detect wrong access from the kernel
to user buffers like this: SMAP triggers a permissions violation on
wrong access.  In the x86-64 variant of clear_user(), SMAP is properly
handled via clac()+stac().

To fix, properly use clear_user() when we're dealing with a user buffer.</Note>
    </Notes>
    <CVE>CVE-2021-47566</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

staging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect()

The free_rtllib() function frees the "dev" pointer so there is use
after free on the next line.  Re-arrange things to avoid that.</Note>
    </Notes>
    <CVE>CVE-2021-47571</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: scsi_debug: Sanity check block descriptor length in resp_mode_select()

In resp_mode_select() sanity check the block descriptor len to avoid UAF.

BUG: KASAN: use-after-free in resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509
Read of size 1 at addr ffff888026670f50 by task scsicmd/15032

CPU: 1 PID: 15032 Comm: scsicmd Not tainted 5.15.0-01d0625 #15
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:107
 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:257
 kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:443
 __asan_report_load1_noabort+0x14/0x20 mm/kasan/report_generic.c:306
 resp_mode_select+0xa4c/0xb40 drivers/scsi/scsi_debug.c:2509
 schedule_resp+0x4af/0x1a10 drivers/scsi/scsi_debug.c:5483
 scsi_debug_queuecommand+0x8c9/0x1e70 drivers/scsi/scsi_debug.c:7537
 scsi_queue_rq+0x16b4/0x2d10 drivers/scsi/scsi_lib.c:1521
 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1640
 __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:1762
 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1839
 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:63
 sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:837
 sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:775
 sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:941
 sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1166
 __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:52
 do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:50
 entry_SYSCALL_64_after_hwframe+0x44/0xae arch/x86/entry/entry_64.S:113</Note>
    </Notes>
    <CVE>CVE-2021-47576</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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: systemport: Add global locking for descriptor lifecycle

The descriptor list is a shared resource across all of the transmit queues, and
the locking mechanism used today only protects concurrency across a given
transmit queue between the transmit and reclaiming. This creates an opportunity
for the SYSTEMPORT hardware to work on corrupted descriptors if we have
multiple producers at once which is the case when using multiple transmit
queues.

This was particularly noticeable when using multiple flows/transmit queues and
it showed up in interesting ways in that UDP packets would get a correct UDP
header checksum being calculated over an incorrect packet length. Similarly TCP
packets would get an equally correct checksum computed by the hardware over an
incorrect packet length.

The SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges
when the driver produces a new descriptor anytime it writes to the
WRITE_PORT_{HI,LO} registers, there is however some delay in the hardware to
re-organize its descriptors and it is possible that concurrent TX queues
eventually break this internal allocation scheme to the point where the
length/status part of the descriptor gets used for an incorrect data buffer.

The fix is to impose a global serialization for all TX queues in the short
section where we are writing to the WRITE_PORT_{HI,LO} registers which solves
the corruption even with multiple concurrent TX queues being used.</Note>
    </Notes>
    <CVE>CVE-2021-47587</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

igbvf: fix double free in `igbvf_probe`

In `igbvf_probe`, if register_netdev() fails, the program will go to
label err_hw_init, and then to label err_ioremap. In free_netdev() which
is just below label err_ioremap, there is `list_for_each_entry_safe` and
`netif_napi_del` which aims to delete all entries in `dev-&gt;napi_list`.
The program has added an entry `adapter-&gt;rx_ring-&gt;napi` which is added by
`netif_napi_add` in igbvf_alloc_queues(). However, adapter-&gt;rx_ring has
been freed below label err_hw_init. So this a UAF.

In terms of how to patch the problem, we can refer to igbvf_remove() and
delete the entry before `adapter-&gt;rx_ring`.

The KASAN logs are as follows:

[   35.126075] BUG: KASAN: use-after-free in free_netdev+0x1fd/0x450
[   35.127170] Read of size 8 at addr ffff88810126d990 by task modprobe/366
[   35.128360]
[   35.128643] CPU: 1 PID: 366 Comm: modprobe Not tainted 5.15.0-rc2+ #14
[   35.129789] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[   35.131749] Call Trace:
[   35.132199]  dump_stack_lvl+0x59/0x7b
[   35.132865]  print_address_description+0x7c/0x3b0
[   35.133707]  ? free_netdev+0x1fd/0x450
[   35.134378]  __kasan_report+0x160/0x1c0
[   35.135063]  ? free_netdev+0x1fd/0x450
[   35.135738]  kasan_report+0x4b/0x70
[   35.136367]  free_netdev+0x1fd/0x450
[   35.137006]  igbvf_probe+0x121d/0x1a10 [igbvf]
[   35.137808]  ? igbvf_vlan_rx_add_vid+0x100/0x100 [igbvf]
[   35.138751]  local_pci_probe+0x13c/0x1f0
[   35.139461]  pci_device_probe+0x37e/0x6c0
[   35.165526]
[   35.165806] Allocated by task 366:
[   35.166414]  ____kasan_kmalloc+0xc4/0xf0
[   35.167117]  foo_kmem_cache_alloc_trace+0x3c/0x50 [igbvf]
[   35.168078]  igbvf_probe+0x9c5/0x1a10 [igbvf]
[   35.168866]  local_pci_probe+0x13c/0x1f0
[   35.169565]  pci_device_probe+0x37e/0x6c0
[   35.179713]
[   35.179993] Freed by task 366:
[   35.180539]  kasan_set_track+0x4c/0x80
[   35.181211]  kasan_set_free_info+0x1f/0x40
[   35.181942]  ____kasan_slab_free+0x103/0x140
[   35.182703]  kfree+0xe3/0x250
[   35.183239]  igbvf_probe+0x1173/0x1a10 [igbvf]
[   35.184040]  local_pci_probe+0x13c/0x1f0</Note>
    </Notes>
    <CVE>CVE-2021-47589</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 btree remove: fix use after free in rebalance_children()

Move dm_tm_unlock() after dm_tm_dec().</Note>
    </Notes>
    <CVE>CVE-2021-47600</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: track only QoS data frames for admission control

For admission control, obviously all of that only works for
QoS data frames, otherwise we cannot even access the QoS
field in the header.

Syzbot reported (see below) an uninitialized value here due
to a status of a non-QoS nullfunc packet, which isn't even
long enough to contain the QoS header.

Fix this to only do anything for QoS data packets.</Note>
    </Notes>
    <CVE>CVE-2021-47602</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

audit: improve robustness of the audit queue handling

If the audit daemon were ever to get stuck in a stopped state the
kernel's kauditd_thread() could get blocked attempting to send audit
records to the userspace audit daemon.  With the kernel thread
blocked it is possible that the audit queue could grow unbounded as
certain audit record generating events must be exempt from the queue
limits else the system enter a deadlock state.

This patch resolves this problem by lowering the kernel thread's
socket sending timeout from MAX_SCHEDULE_TIMEOUT to HZ/10 and tweaks
the kauditd_send_queue() function to better manage the various audit
queues when connection problems occur between the kernel and the
audit daemon.  With this patch, the backlog may temporarily grow
beyond the defined limits when the audit daemon is stopped and the
system is under heavy audit pressure, but kauditd_thread() will
continue to make progress and drain the queues as it would for other
connection problems.  For example, with the audit daemon put into a
stopped state and the system configured to audit every syscall it
was still possible to shutdown the system without a kernel panic,
deadlock, etc.; granted, the system was slow to shutdown but that is
to be expected given the extreme pressure of recording every syscall.

The timeout value of HZ/10 was chosen primarily through
experimentation and this developer's "gut feeling".  There is likely
no one perfect value, but as this scenario is limited in scope (root
privileges would be needed to send SIGSTOP to the audit daemon), it
is likely not worth exposing this as a tunable at present.  This can
always be done at a later date if it proves necessary.</Note>
    </Notes>
    <CVE>CVE-2021-47603</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_scpi: Fix string overflow in SCPI genpd driver

Without the bound checks for scpi_pd-&gt;name, it could result in the buffer
overflow when copying the SCPI device name from the corresponding device
tree node as the name string is set at maximum size of 30.

Let us fix it by using devm_kasprintf so that the string buffer is
allocated dynamically.</Note>
    </Notes>
    <CVE>CVE-2021-47609</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: pciehp: Fix infinite loop in IRQ handler upon power fault

The Power Fault Detected bit in the Slot Status register differs from
all other hotplug events in that it is sticky:  It can only be cleared
after turning off slot power.  Per PCIe r5.0, sec. 6.7.1.8:

  If a power controller detects a main power fault on the hot-plug slot,
  it must automatically set its internal main power fault latch [...].
  The main power fault latch is cleared when software turns off power to
  the hot-plug slot.

The stickiness used to cause interrupt storms and infinite loops which
were fixed in 2009 by commits 5651c48cfafe ("PCI pciehp: fix power fault
interrupt storm problem") and 99f0169c17f3 ("PCI: pciehp: enable
software notification on empty slots").

Unfortunately in 2020 the infinite loop issue was inadvertently
reintroduced by commit 8edf5332c393 ("PCI: pciehp: Fix MSI interrupt
race"):  The hardirq handler pciehp_isr() clears the PFD bit until
pciehp's power_fault_detected flag is set.  That happens in the IRQ
thread pciehp_ist(), which never learns of the event because the hardirq
handler is stuck in an infinite loop.  Fix by setting the
power_fault_detected flag already in the hardirq handler.</Note>
    </Notes>
    <CVE>CVE-2021-47617</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A stack overflow flaw was found in the Linux kernel's TIPC protocol functionality in the way a user sends a packet with malicious content where the number of domain member nodes is higher than the 64 allowed. This flaw allows a remote user to crash the system or possibly escalate their privileges if they have access to the TIPC network.</Note>
    </Notes>
    <CVE>CVE-2022-0435</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>9</BaseScore>
        <Vector>AV:N/AC:L/Au:S/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">A use-after-free vulnerability was found in rtsx_usb_ms_drv_remove in drivers/memstick/host/rtsx_usb_ms.c in memstick in the Linux kernel. In this flaw, a local attacker with a user privilege may impact system Confidentiality. This flaw affects kernel versions prior to 5.14 rc1.</Note>
    </Notes>
    <CVE>CVE-2022-0487</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>2.1</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:P/I:N/A:N</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The vmwgfx driver contains a local privilege escalation vulnerability that allows unprivileged users to gain access to files opened by other processes on the system through a dangling 'file' pointer.</Note>
    </Notes>
    <CVE>CVE-2022-22942</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">xmlparse.c in Expat (aka libexpat) before 2.4.5 allows attackers to insert namespace-separator characters into namespace URIs.</Note>
    </Notes>
    <CVE>CVE-2022-25236</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>7.5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:P/I:P/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">There's a possible overflow in handle_image() when shim tries to load and execute crafted EFI executables; The handle_image() function takes into account the SizeOfRawData field from each section to be loaded. An attacker can leverage this to perform out-of-bound writes into memory. Arbitrary code execution is not discarded in such scenario.</Note>
    </Notes>
    <CVE>CVE-2022-28737</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:shim-15.8-25.30.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 use-after-free exists in Python through 3.9 via heappushpop in heapq.</Note>
    </Notes>
    <CVE>CVE-2022-48560</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libpython2_7-1_0-2.7.18-33.35.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-2.7.18-33.35.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-base-2.7.18-33.35.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-xml-2.7.18-33.35.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 drivers/input/input.c in the Linux kernel before 5.17.10. An attacker can cause a denial of service (panic) because input_set_capability mishandles the situation in which an event code falls outside of a bitmap.</Note>
    </Notes>
    <CVE>CVE-2022-48619</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup

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

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

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

scsi: qla2xxx: Fix memory leak in __qlt_24xx_handle_abts()

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

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

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

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

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

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

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

This patch replaces eth_hdr() with skb_eth_hdr() in ipvlan_xmit_mode_l2()
and reset mac header in multicast to solve this out-of-bound bug.</Note>
    </Notes>
    <CVE>CVE-2022-48651</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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:

smb3: fix temporary data corruption in insert range

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

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

smb3: fix temporary data corruption in collapse range

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

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

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

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

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

nvme-tcp: fix UAF when detecting digest errors

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

i40e: Fix kernel crash during module removal

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

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

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

Two offline tests cause IRDMA driver failure (ETIMEDOUT) and this
failure is indicated back to i40e_client_subtask() that calls
i40e_client_del_instance() to free client instance referenced
by pf-&gt;cinst and sets this pointer to NULL. During the module
removal i40e_remove() calls i40e_lan_del_device() that dereferences
pf-&gt;cinst that is NULL -&gt; crash.
Do not remove client instance when client open callbacks fails and
just clear __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needs
to take care about this situation (when netdev is up and client
is NOT opened) in i40e_notify_client_of_netdev_close() and
calls client close callback only when __I40E_CLIENT_INSTANCE_OPENED
is set.</Note>
    </Notes>
    <CVE>CVE-2022-48688</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: mpt3sas: Fix use-after-free warning

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

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

nvmet: fix a use-after-free

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

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

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

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

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

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

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

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

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

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

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

Although radeon card fence and wait for gpu to finish processing current batch rings,
there is still a corner case that radeon lockup work queue may not be fully flushed,
and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to
put device in D3hot state.
Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.
&gt; Configuration and Message requests are the only TLPs accepted by a Function in
&gt; the D3hot state. All other received Requests must be handled as Unsupported Requests,
&gt; and all received Completions may optionally be handled as Unexpected Completions.
This issue will happen in following logs:
Unable to handle kernel paging request at virtual address 00008800e0008010
CPU 0 kworker/0:3(131): Oops 0
pc = [&lt;ffffffff811bea5c&gt;]  ra = [&lt;ffffffff81240844&gt;]  ps = 0000 Tainted: G        W
pc is at si_gpu_check_soft_reset+0x3c/0x240
ra is at si_dma_is_lockup+0x34/0xd0
v0 = 0000000000000000  t0 = fff08800e0008010  t1 = 0000000000010000
t2 = 0000000000008010  t3 = fff00007e3c00000  t4 = fff00007e3c00258
t5 = 000000000000ffff  t6 = 0000000000000001  t7 = fff00007ef078000
s0 = fff00007e3c016e8  s1 = fff00007e3c00000  s2 = fff00007e3c00018
s3 = fff00007e3c00000  s4 = fff00007fff59d80  s5 = 0000000000000000
s6 = fff00007ef07bd98
a0 = fff00007e3c00000  a1 = fff00007e3c016e8  a2 = 0000000000000008
a3 = 0000000000000001  a4 = 8f5c28f5c28f5c29  a5 = ffffffff810f4338
t8 = 0000000000000275  t9 = ffffffff809b66f8  t10 = ff6769c5d964b800
t11= 000000000000b886  pv = ffffffff811bea20  at = 0000000000000000
gp = ffffffff81d89690  sp = 00000000aa814126
Disabling lock debugging due to kernel taint
Trace:
[&lt;ffffffff81240844&gt;] si_dma_is_lockup+0x34/0xd0
[&lt;ffffffff81119610&gt;] radeon_fence_check_lockup+0xd0/0x290
[&lt;ffffffff80977010&gt;] process_one_work+0x280/0x550
[&lt;ffffffff80977350&gt;] worker_thread+0x70/0x7c0
[&lt;ffffffff80977410&gt;] worker_thread+0x130/0x7c0
[&lt;ffffffff80982040&gt;] kthread+0x200/0x210
[&lt;ffffffff809772e0&gt;] worker_thread+0x0/0x7c0
[&lt;ffffffff80981f8c&gt;] kthread+0x14c/0x210
[&lt;ffffffff80911658&gt;] ret_from_kernel_thread+0x18/0x20
[&lt;ffffffff80981e40&gt;] kthread+0x0/0x210
 Code: ad3e0008  43f0074a  ad7e0018  ad9e0020  8c3001e8  40230101
 &lt;88210000&gt; 4821ed21
So force lockup work queue flush to fix this problem.</Note>
    </Notes>
    <CVE>CVE-2022-48704</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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

Added checking of pointer "function" in pcs_set_mux().
pinmux_generic_get_function() can return NULL and the pointer
"function" was dereferenced without checking against NULL.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2022-48708</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 a possible null pointer dereference

In radeon_fp_native_mode(), 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.

The failure status of drm_cvt_mode() on the other path is checked too.</Note>
    </Notes>
    <CVE>CVE-2022-48710</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Make bnx2fc_recv_frame() mp safe

Running tests with a debug kernel shows that bnx2fc_recv_frame() is
modifying the per_cpu lport stats counters in a non-mpsafe way.  Just boot
a debug kernel and run the bnx2fc driver with the hardware enabled.

[ 1391.699147] BUG: using smp_processor_id() in preemptible [00000000] code: bnx2fc_
[ 1391.699160] caller is bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]
[ 1391.699174] CPU: 2 PID: 4355 Comm: bnx2fc_l2_threa Kdump: loaded Tainted: G    B
[ 1391.699180] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
[ 1391.699183] Call Trace:
[ 1391.699188]  dump_stack_lvl+0x57/0x7d
[ 1391.699198]  check_preemption_disabled+0xc8/0xd0
[ 1391.699205]  bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]
[ 1391.699215]  ? do_raw_spin_trylock+0xb5/0x180
[ 1391.699221]  ? bnx2fc_npiv_create_vports.isra.0+0x4e0/0x4e0 [bnx2fc]
[ 1391.699229]  ? bnx2fc_l2_rcv_thread+0xb7/0x3a0 [bnx2fc]
[ 1391.699240]  bnx2fc_l2_rcv_thread+0x1af/0x3a0 [bnx2fc]
[ 1391.699250]  ? bnx2fc_ulp_init+0xc0/0xc0 [bnx2fc]
[ 1391.699258]  kthread+0x364/0x420
[ 1391.699263]  ? _raw_spin_unlock_irq+0x24/0x50
[ 1391.699268]  ? set_kthread_struct+0x100/0x100
[ 1391.699273]  ret_from_fork+0x22/0x30

Restore the old get_cpu/put_cpu code with some modifications to reduce the
size of the critical section.</Note>
    </Notes>
    <CVE>CVE-2022-48715</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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: ieee802154: ca8210: Stop leaking skb's

Upon error the ieee802154_xmit_complete() helper is not called. Only
ieee802154_wake_queue() is called manually. We then leak the skb
structure.

Free the skb structure upon error before returning.</Note>
    </Notes>
    <CVE>CVE-2022-48722</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 off by one in BIOS boundary checking

Bounds checking when parsing init scripts embedded in the BIOS reject
access to the last byte. This causes driver initialization to fail on
Apple eMac's with GeForce 2 MX GPUs, leaving the system with no working
console.

This is probably only seen on OpenFirmware machines like PowerPC Macs
because the BIOS image provided by OF is only the used parts of the ROM,
not a power-of-two blocks read from PCI directly so PCs always have
empty bytes at the end that are never accessed.</Note>
    </Notes>
    <CVE>CVE-2022-48732</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use-after-free after failure to create a snapshot

At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and
then attach it to the transaction's list of pending snapshots. After that
we call btrfs_commit_transaction(), and if that returns an error we jump
to 'fail' label, where we kfree() the pending snapshot structure. This can
result in a later use-after-free of the pending snapshot:

1) We allocated the pending snapshot and added it to the transaction's
   list of pending snapshots;

2) We call btrfs_commit_transaction(), and it fails either at the first
   call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups().
   In both cases, we don't abort the transaction and we release our
   transaction handle. We jump to the 'fail' label and free the pending
   snapshot structure. We return with the pending snapshot still in the
   transaction's list;

3) Another task commits the transaction. This time there's no error at
   all, and then during the transaction commit it accesses a pointer
   to the pending snapshot structure that the snapshot creation task
   has already freed, resulting in a user-after-free.

This issue could actually be detected by smatch, which produced the
following warning:

  fs/btrfs/ioctl.c:843 create_snapshot() warn: '&amp;pending_snapshot-&gt;list' not removed from list

So fix this by not having the snapshot creation ioctl directly add the
pending snapshot to the transaction's list. Instead add the pending
snapshot to the transaction handle, and then at btrfs_commit_transaction()
we add the snapshot to the list only when we can guarantee that any error
returned after that point will result in a transaction abort, in which
case the ioctl code can safely free the pending snapshot and no one can
access it anymore.</Note>
    </Notes>
    <CVE>CVE-2022-48733</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

selinux: fix double free of cond_list on error paths

On error path from cond_read_list() and duplicate_policydb_cond_list()
the cond_list_destroy() gets called a second time in caller functions,
resulting in NULL pointer deref.  Fix this by resetting the
cond_list_len to 0 in cond_list_destroy(), making subsequent calls a
noop.

Also consistently reset the cond_list pointer to NULL after freeing.

[PM: fix line lengths in the description]</Note>
    </Notes>
    <CVE>CVE-2022-48740</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: amd-xgbe: Fix skb data length underflow

There will be BUG_ON() triggered in include/linux/skbuff.h leading to
intermittent kernel panic, when the skb length underflow is detected.

Fix this by dropping the packet if such length underflows are seen
because of inconsistencies in the hardware descriptors.</Note>
    </Notes>
    <CVE>CVE-2022-48743</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

phylib: fix potential use-after-free

Commit bafbdd527d56 ("phylib: Add device reset GPIO support") added call
to phy_device_reset(phydev) after the put_device() call in phy_detach().

The comment before the put_device() call says that the phydev might go
away with put_device().

Fix potential use-after-free by calling phy_device_reset() before
put_device().</Note>
    </Notes>
    <CVE>CVE-2022-48754</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/dsi: invalid parameter check in msm_dsi_phy_enable

The function performs a check on the "phy" input parameter, however, it
is used before the check.

Initialize the "dev" variable after the sanity check to avoid a possible
NULL pointer dereference.

Addresses-Coverity-ID: 1493860 ("Null pointer dereference")</Note>
    </Notes>
    <CVE>CVE-2022-48756</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Flush destroy_work queue before calling bnx2fc_interface_put()

The bnx2fc_destroy() functions are removing the interface before calling
destroy_work. This results multiple WARNings from sysfs_remove_group() as
the controller rport device attributes are removed too early.

Replace the fcoe_port's destroy_work queue. It's not needed.

The problem is easily reproducible with the following steps.

Example:

  $ dmesg -w &amp;
  $ systemctl enable --now fcoe
  $ fipvlan -s -c ens2f1
  $ fcoeadm -d ens2f1.802
  [  583.464488] host2: libfc: Link down on port (7500a1)
  [  583.472651] bnx2fc: 7500a1 - rport not created Yet!!
  [  583.490468] ------------[ cut here ]------------
  [  583.538725] sysfs group 'power' not found for kobject 'rport-2:0-0'
  [  583.568814] WARNING: CPU: 3 PID: 192 at fs/sysfs/group.c:279 sysfs_remove_group+0x6f/0x80
  [  583.607130] Modules linked in: dm_service_time 8021q garp mrp stp llc bnx2fc cnic uio rpcsec_gss_krb5 auth_rpcgss nfsv4 ...
  [  583.942994] CPU: 3 PID: 192 Comm: kworker/3:2 Kdump: loaded Not tainted 5.14.0-39.el9.x86_64 #1
  [  583.984105] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
  [  584.016535] Workqueue: fc_wq_2 fc_rport_final_delete [scsi_transport_fc]
  [  584.050691] RIP: 0010:sysfs_remove_group+0x6f/0x80
  [  584.074725] Code: ff 5b 48 89 ef 5d 41 5c e9 ee c0 ff ff 48 89 ef e8 f6 b8 ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 ...
  [  584.162586] RSP: 0018:ffffb567c15afdc0 EFLAGS: 00010282
  [  584.188225] RAX: 0000000000000000 RBX: ffffffff8eec4220 RCX: 0000000000000000
  [  584.221053] RDX: ffff8c1586ce84c0 RSI: ffff8c1586cd7cc0 RDI: ffff8c1586cd7cc0
  [  584.255089] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb567c15afc00
  [  584.287954] R10: ffffb567c15afbf8 R11: ffffffff8fbe7f28 R12: ffff8c1486326400
  [  584.322356] R13: ffff8c1486326480 R14: ffff8c1483a4a000 R15: 0000000000000004
  [  584.355379] FS:  0000000000000000(0000) GS:ffff8c1586cc0000(0000) knlGS:0000000000000000
  [  584.394419] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [  584.421123] CR2: 00007fe95a6f7840 CR3: 0000000107674002 CR4: 00000000000606e0
  [  584.454888] Call Trace:
  [  584.466108]  device_del+0xb2/0x3e0
  [  584.481701]  device_unregister+0x13/0x60
  [  584.501306]  bsg_unregister_queue+0x5b/0x80
  [  584.522029]  bsg_remove_queue+0x1c/0x40
  [  584.541884]  fc_rport_final_delete+0xf3/0x1d0 [scsi_transport_fc]
  [  584.573823]  process_one_work+0x1e3/0x3b0
  [  584.592396]  worker_thread+0x50/0x3b0
  [  584.609256]  ? rescuer_thread+0x370/0x370
  [  584.628877]  kthread+0x149/0x170
  [  584.643673]  ? set_kthread_struct+0x40/0x40
  [  584.662909]  ret_from_fork+0x22/0x30
  [  584.680002] ---[ end trace 53575ecefa942ece ]---</Note>
    </Notes>
    <CVE>CVE-2022-48758</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

rpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev

struct rpmsg_ctrldev contains a struct cdev. The current code frees
the rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but the
cdev is a managed object, therefore its release is not predictable
and the rpmsg_ctrldev could be freed before the cdev is entirely
released, as in the backtrace below.

[   93.625603] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x7c
[   93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_print_object+0x13c/0x1b0
[   93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif_hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vmalloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v
[   93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G    B             5.4.163-lockdep #26
[   93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)
[   93.730055] Workqueue: events kobject_delayed_cleanup
[   93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO)
[   93.740216] pc : debug_print_object+0x13c/0x1b0
[   93.744890] lr : debug_print_object+0x13c/0x1b0
[   93.749555] sp : ffffffacf5bc7940
[   93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000
[   93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000
[   93.763916] x25: ffffffd0734f856c x24: dfffffd000000000
[   93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0
[   93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0
[   93.780338] x19: ffffffd075199100 x18: 00000000000276e0
[   93.785814] x17: 0000000000000000 x16: dfffffd000000000
[   93.791291] x15: ffffffffffffffff x14: 6e6968207473696c
[   93.796768] x13: 0000000000000000 x12: ffffffd075e2b000
[   93.802244] x11: 0000000000000001 x10: 0000000000000000
[   93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900
[   93.813200] x7 : 0000000000000000 x6 : 0000000000000000
[   93.818676] x5 : 0000000000000080 x4 : 0000000000000000
[   93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001
[   93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061
[   93.835104] Call trace:
[   93.837644]  debug_print_object+0x13c/0x1b0
[   93.841963]  __debug_check_no_obj_freed+0x25c/0x3c0
[   93.846987]  debug_check_no_obj_freed+0x18/0x20
[   93.851669]  slab_free_freelist_hook+0xbc/0x1e4
[   93.856346]  kfree+0xfc/0x2f4
[   93.859416]  rpmsg_ctrldev_release_device+0x78/0xb8
[   93.864445]  device_release+0x84/0x168
[   93.868310]  kobject_cleanup+0x12c/0x298
[   93.872356]  kobject_delayed_cleanup+0x10/0x18
[   93.876948]  process_one_work+0x578/0x92c
[   93.881086]  worker_thread+0x804/0xcf8
[   93.884963]  kthread+0x2a8/0x314
[   93.888303]  ret_from_fork+0x10/0x18

The cdev_device_add/del() API was created to address this issue (see
commit '233ed09d7fda ("chardev: add helper function to register char
devs with a struct device")'), use it instead of cdev add/del().</Note>
    </Notes>
    <CVE>CVE-2022-48759</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 hang in usb_kill_urb by adding memory barriers

The syzbot fuzzer has identified a bug in which processes hang waiting
for usb_kill_urb() to return.  It turns out the issue is not unlinking
the URB; that works just fine.  Rather, the problem arises when the
wakeup notification that the URB has completed is not received.

The reason is memory-access ordering on SMP systems.  In outline form,
usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on
different CPUs perform the following actions:

CPU 0					CPU 1
----------------------------		---------------------------------
usb_kill_urb():				__usb_hcd_giveback_urb():
  ...					  ...
  atomic_inc(&amp;urb-&gt;reject);		  atomic_dec(&amp;urb-&gt;use_count);
  ...					  ...
  wait_event(usb_kill_urb_queue,
	atomic_read(&amp;urb-&gt;use_count) == 0);
					  if (atomic_read(&amp;urb-&gt;reject))
						wake_up(&amp;usb_kill_urb_queue);

Confining your attention to urb-&gt;reject and urb-&gt;use_count, you can
see that the overall pattern of accesses on CPU 0 is:

	write urb-&gt;reject, then read urb-&gt;use_count;

whereas the overall pattern of accesses on CPU 1 is:

	write urb-&gt;use_count, then read urb-&gt;reject.

This pattern is referred to in memory-model circles as SB (for "Store
Buffering"), and it is well known that without suitable enforcement of
the desired order of accesses -- in the form of memory barriers -- it
is entirely possible for one or both CPUs to execute their reads ahead
of their writes.  The end result will be that sometimes CPU 0 sees the
old un-decremented value of urb-&gt;use_count while CPU 1 sees the old
un-incremented value of urb-&gt;reject.  Consequently CPU 0 ends up on
the wait queue and never gets woken up, leading to the observed hang
in usb_kill_urb().

The same pattern of accesses occurs in usb_poison_urb() and the
failure pathway of usb_hcd_submit_urb().

The problem is fixed by adding suitable memory barriers.  To provide
proper memory-access ordering in the SB pattern, a full barrier is
required on both CPUs.  The atomic_inc() and atomic_dec() accesses
themselves don't provide any memory ordering, but since they are
present, we can use the optimized smp_mb__after_atomic() memory
barrier in the various routines to obtain the desired effect.

This patch adds the necessary memory barriers.</Note>
    </Notes>
    <CVE>CVE-2022-48760</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-plat: fix crash when suspend if remote wake enable

Crashed at i.mx8qm platform when suspend if enable remote wakeup

Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 244 Comm: kworker/u12:6 Not tainted 5.15.5-dirty #12
Hardware name: Freescale i.MX8QM MEK (DT)
Workqueue: events_unbound async_run_entry_fn
pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : xhci_disable_hub_port_wake.isra.62+0x60/0xf8
lr : xhci_disable_hub_port_wake.isra.62+0x34/0xf8
sp : ffff80001394bbf0
x29: ffff80001394bbf0 x28: 0000000000000000 x27: ffff00081193b578
x26: ffff00081193b570 x25: 0000000000000000 x24: 0000000000000000
x23: ffff00081193a29c x22: 0000000000020001 x21: 0000000000000001
x20: 0000000000000000 x19: ffff800014e90490 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000960 x9 : ffff80001394baa0
x8 : ffff0008145d1780 x7 : ffff0008f95b8e80 x6 : 000000001853b453
x5 : 0000000000000496 x4 : 0000000000000000 x3 : ffff00081193a29c
x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff000814591620
Call trace:
 xhci_disable_hub_port_wake.isra.62+0x60/0xf8
 xhci_suspend+0x58/0x510
 xhci_plat_suspend+0x50/0x78
 platform_pm_suspend+0x2c/0x78
 dpm_run_callback.isra.25+0x50/0xe8
 __device_suspend+0x108/0x3c0

The basic flow:
	1. run time suspend call xhci_suspend, xhci parent devices gate the clock.
        2. echo mem &gt;/sys/power/state, system _device_suspend call xhci_suspend
        3. xhci_suspend call xhci_disable_hub_port_wake, which access register,
	   but clock already gated by run time suspend.

This problem was hidden by power domain driver, which call run time resume before it.

But the below commit remove it and make this issue happen.
	commit c1df456d0f06e ("PM: domains: Don't runtime resume devices at genpd_prepare()")

This patch call run time resume before suspend to make sure clock is on
before access register.

Testeb-by: Abel Vesa &lt;abel.vesa@nxp.com&gt;</Note>
    </Notes>
    <CVE>CVE-2022-48761</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: lgdt3306a: Add a check against null-pointer-def

The driver should check whether the client provides the platform_data.

The following log reveals it:

[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[   29.612820] Call Trace:
[   29.613030]  &lt;TASK&gt;
[   29.613201]  dump_stack_lvl+0x56/0x6f
[   29.613496]  ? kmemdup+0x30/0x40
[   29.613754]  print_report.cold+0x494/0x6b7
[   29.614082]  ? kmemdup+0x30/0x40
[   29.614340]  kasan_report+0x8a/0x190
[   29.614628]  ? kmemdup+0x30/0x40
[   29.614888]  kasan_check_range+0x14d/0x1d0
[   29.615213]  memcpy+0x20/0x60
[   29.615454]  kmemdup+0x30/0x40
[   29.615700]  lgdt3306a_probe+0x52/0x310
[   29.616339]  i2c_device_probe+0x951/0xa90</Note>
    </Notes>
    <CVE>CVE-2022-48772</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 deadlock flaw was found in the Linux kernel's BPF subsystem. This flaw allows a local user to potentially crash the system.</Note>
    </Notes>
    <CVE>CVE-2023-0160</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A use-after-free vulnerability in the Linux Kernel traffic control index filter (tcindex) can be exploited to achieve local privilege escalation.  The tcindex_delete function which does not properly deactivate filters in case of a perfect hashes while deleting the underlying structure which can later lead to double freeing the structure.  A local attacker user can use this vulnerability to elevate its privileges to root.
We recommend upgrading past commit 8c710f75256bb3cf05ac7b1672c82b92c43f3d28.

</Note>
    </Notes>
    <CVE>CVE-2023-1829</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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">Bluetooth BR/EDR devices with Secure Simple Pairing and Secure Connections pairing in Bluetooth Core Specification 4.2 through 5.4 allow certain man-in-the-middle attacks that force a short key length, and might lead to discovery of the encryption key and live injection, aka BLUFFS.</Note>
    </Notes>
    <CVE>CVE-2023-24023</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 email module of Python through 3.11.3 incorrectly parses e-mail addresses that contain a special character. The wrong portion of an RFC2822 header is identified as the value of the addr-spec. In some applications, an attacker can bypass a protection mechanism in which application access is granted only after verifying receipt of e-mail to a specific domain (e.g., only @company.example.com addresses may be used for signup). This occurs in email/_parseaddr.py in recent versions of Python.</Note>
    </Notes>
    <CVE>CVE-2023-27043</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libpython2_7-1_0-2.7.18-33.35.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-2.7.18-33.35.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-base-2.7.18-33.35.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-xml-2.7.18-33.35.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An out-of-bounds read vulnerability was found in the SR-IPv6 implementation in the Linux kernel. The flaw exists within the processing of seg6 attributes. The issue results from the improper validation of user-supplied data, which can result in a read past the end of an allocated buffer. This flaw allows a privileged local user to disclose sensitive information on affected installations of the Linux kernel.</Note>
    </Notes>
    <CVE>CVE-2023-2860</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Information exposure through microarchitectural state after transient execution from some register files for some Intel(R) Atom(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.</Note>
    </Notes>
    <CVE>CVE-2023-28746</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was discovered in the Linux kernel through 6.3.8. A use-after-free was found in ravb_remove in drivers/net/ethernet/renesas/ravb_main.c.</Note>
    </Notes>
    <CVE>CVE-2023-35827</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 Avahi. A reachable assertion exists in the avahi_escape_label() function.</Note>
    </Notes>
    <CVE>CVE-2023-38470</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libavahi-client3-0.6.32-32.27.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libavahi-common3-0.6.32-32.27.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in Avahi. A reachable assertion exists in the avahi_rdata_parse() function.</Note>
    </Notes>
    <CVE>CVE-2023-38472</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libavahi-client3-0.6.32-32.27.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libavahi-common3-0.6.32-32.27.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in Shim when an error happened while creating a new ESL variable. If Shim fails to create the new variable, it tries to print an error message to the user; however, the number of parameters used by the logging function doesn't match the format string used by it, leading to a crash under certain circumstances.</Note>
    </Notes>
    <CVE>CVE-2023-40546</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:shim-15.8-25.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">A remote code execution vulnerability was found in Shim. The Shim boot support trusts attacker-controlled values when parsing an HTTP response. This flaw allows an attacker to craft a specific malicious HTTP request, leading to a completely controlled out-of-bounds write primitive and complete system compromise. This flaw is only exploitable during the early boot phase, an attacker needs to perform a Man-in-the-Middle or compromise the boot server to be able to exploit this vulnerability successfully.</Note>
    </Notes>
    <CVE>CVE-2023-40547</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:shim-15.8-25.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">A buffer overflow was found in Shim in the 32-bit system. The overflow happens due to an addition operation involving a user-controlled value parsed from the PE binary being used by Shim. This value is further used for memory allocation operations, leading to a heap-based buffer overflow. This flaw causes memory corruption and can lead to a crash or data integrity issues during the boot phase.</Note>
    </Notes>
    <CVE>CVE-2023-40548</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:shim-15.8-25.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">An out-of-bounds read flaw was found in Shim when it tried to validate the SBAT information. This issue may expose sensitive data during the system's boot phase.</Note>
    </Notes>
    <CVE>CVE-2023-40550</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:shim-15.8-25.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">A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.

Due to a race condition between nf_tables netlink control plane transaction and nft_set element garbage collection, it is possible to underflow the reference counter causing a use-after-free vulnerability.

We recommend upgrading past commit 3e91b0ebd994635df2346353322ac51ce84ce6d8.

</Note>
    </Notes>
    <CVE>CVE-2023-4244</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 IPv4 Resource Reservation Protocol (RSVP) classifier in the Linux kernel. The xprt pointer may go beyond the linear part of the skb, leading to an out-of-bounds read in the `rsvp_classify` function. This issue may allow a local user to crash the system and cause a denial of service.</Note>
    </Notes>
    <CVE>CVE-2023-42755</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 DNS message parsing code in `named` includes a section whose computational complexity is overly high. It does not cause problems for typical DNS traffic, but crafted queries and responses may cause excessive CPU load on the affected `named` instance by exploiting this flaw. This issue affects both authoritative servers and recursive resolvers.
This issue affects BIND 9 versions 9.0.0 through 9.16.45, 9.18.0 through 9.18.21, 9.19.0 through 9.19.19, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.45-S1, and 9.18.11-S1 through 9.18.21-S1.</Note>
    </Notes>
    <CVE>CVE-2023-4408</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:bind-utils-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libbind9-161-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libdns1110-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libirs161-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libisc1107-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libisccc161-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libisccfg163-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:liblwres161-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-bind-9.11.22-3.52.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">The brcm80211 component in the Linux kernel through 6.5.10 has a brcmf_cfg80211_detach use-after-free in the device unplugging (disconnect the USB by hotplug) code. For physically proximate attackers with local access, this "could be exploited in a real world scenario." This is related to brcmf_cfg80211_escan_timeout_worker in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c.</Note>
    </Notes>
    <CVE>CVE-2023-47233</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 ** CVE-2023-4881 was wrongly assigned to a bug that was deemed to be a non-security issue by the Linux kernel security team.</Note>
    </Notes>
    <CVE>CVE-2023-4881</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Certain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035, 6840, and related RFCs) allow remote attackers to cause a denial of service (CPU consumption) via one or more DNSSEC responses, aka the "KeyTrap" issue. One of the concerns is that, when there is a zone with many DNSKEY and RRSIG records, the protocol specification implies that an algorithm must evaluate all combinations of DNSKEY and RRSIG records.</Note>
    </Notes>
    <CVE>CVE-2023-50387</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:bind-utils-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libbind9-161-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libdns1110-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libirs161-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libisc1107-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libisccc161-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libisccfg163-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:liblwres161-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-bind-9.11.22-3.52.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">The Closest Encloser Proof aspect of the DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows remote attackers to cause a denial of service (CPU consumption for SHA-1 computations) via DNSSEC responses in a random subdomain attack, aka the "NSEC3" issue. The RFC 5155 specification implies that an algorithm must perform thousands of iterations of a hash function in certain situations.</Note>
    </Notes>
    <CVE>CVE-2023-50868</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:bind-utils-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libbind9-161-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libdns1110-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libirs161-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libisc1107-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libisccc161-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libisccfg163-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:liblwres161-9.11.22-3.52.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-bind-9.11.22-3.52.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">libexpat through 2.5.0 allows a denial of service (resource consumption) because many full reparsings are required in the case of a large token for which multiple buffer fills are needed.</Note>
    </Notes>
    <CVE>CVE-2023-52425</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libpython2_7-1_0-2.7.18-33.35.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libpython3_4m1_0-3.4.10-25.130.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-2.7.18-33.35.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-base-2.7.18-33.35.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-xml-2.7.18-33.35.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python3-3.4.10-25.130.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python3-base-3.4.10-25.130.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests

hfi1 user SDMA request processing has two bugs that can cause data
corruption for user SDMA requests that have multiple payload iovecs
where an iovec other than the tail iovec does not run up to the page
boundary for the buffer pointed to by that iovec.a

Here are the specific bugs:
1. user_sdma_txadd() does not use struct user_sdma_iovec-&gt;iov.iov_len.
   Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec
   to the packet, even if some of those bytes are past
   iovec-&gt;iov.iov_len and are thus not intended to be in the packet.
2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the
   next iovec in user_sdma_request-&gt;iovs when the current iovec
   is not PAGE_SIZE and does not contain enough data to complete the
   packet. The transmitted packet will contain the wrong data from the
   iovec pages.

This has not been an issue with SDMA packets from hfi1 Verbs or PSM2
because they only produce iovecs that end short of PAGE_SIZE as the tail
iovec of an SDMA request.

Fixing these bugs exposes other bugs with the SDMA pin cache
(struct mmu_rb_handler) that get in way of supporting user SDMA requests
with multiple payload iovecs whose buffers do not end at PAGE_SIZE. So
this commit fixes those issues as well.

Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovec
payload user SDMA requests can hit:
1. Overlapping memory ranges in mmu_rb_handler will result in duplicate
   pinnings.
2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node),
   the mmu_rb code (1) removes the existing entry under a lock, (2)
   releases that lock, pins the new pages, (3) then reacquires the lock
   to insert the extended mmu_rb_node.

   If someone else comes in and inserts an overlapping entry between (2)
   and (3), insert in (3) will fail.

   The failure path code in this case unpins _all_ pages in either the
   original mmu_rb_node or the new mmu_rb_node that was inserted between
   (2) and (3).
3. In hfi1_mmu_rb_remove_unless_exact(), mmu_rb_node-&gt;refcount is
   incremented outside of mmu_rb_handler-&gt;lock. As a result, mmu_rb_node
   could be evicted by another thread that gets mmu_rb_handler-&gt;lock and
   checks mmu_rb_node-&gt;refcount before mmu_rb_node-&gt;refcount is
   incremented.
4. Related to #2 above, SDMA request submission failure path does not
   check mmu_rb_node-&gt;refcount before freeing mmu_rb_node object.

   If there are other SDMA requests in progress whose iovecs have
   pointers to the now-freed mmu_rb_node(s), those pointers to the
   now-freed mmu_rb nodes will be dereferenced when those SDMA requests
   complete.</Note>
    </Notes>
    <CVE>CVE-2023-52474</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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/x86/lbr: Filter vsyscall addresses

We found that a panic can occur when a vsyscall is made while LBR sampling
is active. If the vsyscall is interrupted (NMI) for perf sampling, this
call sequence can occur (most recent at top):

    __insn_get_emulate_prefix()
    insn_get_emulate_prefix()
    insn_get_prefixes()
    insn_get_opcode()
    decode_branch_type()
    get_branch_type()
    intel_pmu_lbr_filter()
    intel_pmu_handle_irq()
    perf_event_nmi_handler()

Within __insn_get_emulate_prefix() at frame 0, a macro is called:

    peek_nbyte_next(insn_byte_t, insn, i)

Within this macro, this dereference occurs:

    (insn)-&gt;next_byte

Inspecting registers at this point, the value of the next_byte field is the
address of the vsyscall made, for example the location of the vsyscall
version of gettimeofday() at 0xffffffffff600000. The access to an address
in the vsyscall region will trigger an oops due to an unhandled page fault.

To fix the bug, filtering for vsyscalls can be done when
determining the branch type. This patch will return
a "none" branch if a kernel address if found to lie in the
vsyscall region.</Note>
    </Notes>
    <CVE>CVE-2023-52476</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: hub: Guard against accesses to uninitialized BOS descriptors

Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
access fields inside udev-&gt;bos without checking if it was allocated and
initialized. If usb_get_bos_descriptor() fails for whatever
reason, udev-&gt;bos will be NULL and those accesses will result in a
crash:

BUG: kernel NULL pointer dereference, address: 0000000000000018
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 &lt;HASH:1f9e 1&gt;
Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021
Workqueue: usb_hub_wq hub_event
RIP: 0010:hub_port_reset+0x193/0x788
Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 &lt;48&gt; 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9
RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310
RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840
RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0
Call Trace:
hub_event+0x73f/0x156e
? hub_activate+0x5b7/0x68f
process_one_work+0x1a2/0x487
worker_thread+0x11a/0x288
kthread+0x13a/0x152
? process_one_work+0x487/0x487
? kthread_associate_blkcg+0x70/0x70
ret_from_fork+0x1f/0x30

Fall back to a default behavior if the BOS descriptor isn't accessible
and skip all the functionalities that depend on it: LPM support checks,
Super Speed capabilitiy checks, U1/U2 states setup.</Note>
    </Notes>
    <CVE>CVE-2023-52477</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Don't unref the same fb many times by mistake due to deadlock handling

If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()
we proceed to unref the fb and then retry the whole thing from the top.
But we forget to reset the fb pointer back to NULL, and so if we then
get another error during the retry, before the fb lookup, we proceed
the unref the same fb again without having gotten another reference.
The end result is that the fb will (eventually) end up being freed
while it's still in use.

Reset fb to NULL once we've unreffed it to avoid doing it again
until we've done another fb lookup.

This turned out to be pretty easy to hit on a DG2 when doing async
flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I
saw that drm_closefb() simply got stuck in a busy loop while walking
the framebuffer list. Fortunately I was able to convince it to oops
instead, and from there it was easier to track down the culprit.</Note>
    </Notes>
    <CVE>CVE-2023-52486</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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

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

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

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

The protocol is used in a bit mask to determine if the protocol is
supported. Assert the provided protocol is less than the maximum
defined so it doesn't potentially perform a shift-out-of-bounds and
provide a clearer error for undefined protocols vs unsupported ones.</Note>
    </Notes>
    <CVE>CVE-2023-52507</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/srp: Do not call scsi_done() from srp_abort()

After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler
callback, it performs one of the following actions:
* Call scsi_queue_insert().
* Call scsi_finish_command().
* Call scsi_eh_scmd_add().
Hence, SCSI abort handlers must not call scsi_done(). Otherwise all
the above actions would trigger a use-after-free. Hence remove the
scsi_done() call from srp_abort(). Keep the srp_free_req() call
before returning SUCCESS because we may not see the command again if
SUCCESS is returned.</Note>
    </Notes>
    <CVE>CVE-2023-52515</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: nfc: llcp: Add lock when modifying device list

The device list needs its associated lock held when modifying it, or the
list could become corrupted, as syzbot discovered.</Note>
    </Notes>
    <CVE>CVE-2023-52524</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()

Including the transhdrlen in length is a problem when the packet is
partially filled (e.g. something like send(MSG_MORE) happened previously)
when appending to an IPv4 or IPv6 packet as we don't want to repeat the
transport header or account for it twice.  This can happen under some
circumstances, such as splicing into an L2TP socket.

The symptom observed is a warning in __ip6_append_data():

    WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800

that occurs when MSG_SPLICE_PAGES is used to append more data to an already
partially occupied skbuff.  The warning occurs when 'copy' is larger than
the amount of data in the message iterator.  This is because the requested
length includes the transport header length when it shouldn't.  This can be
triggered by, for example:

        sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP);
        bind(sfd, ...); // ::1
        connect(sfd, ...); // ::1 port 7
        send(sfd, buffer, 4100, MSG_MORE);
        sendfile(sfd, dfd, NULL, 1024);

Fix this by only adding transhdrlen into the length if the write queue is
empty in l2tp_ip6_sendmsg(), analogously to how UDP does things.

l2tp_ip_sendmsg() looks like it won't suffer from this problem as it builds
the UDP packet itself.</Note>
    </Notes>
    <CVE>CVE-2023-52527</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg

syzbot reported the following uninit-value access issue:

=====================================================
BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x21c/0x280 lib/dump_stack.c:118
 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121
 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
 smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
 usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737
 usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374
 really_probe+0xf20/0x20b0 drivers/base/dd.c:529
 driver_probe_device+0x293/0x390 drivers/base/dd.c:701
 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
 usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032
 usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241
 usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272
 really_probe+0xf20/0x20b0 drivers/base/dd.c:529
 driver_probe_device+0x293/0x390 drivers/base/dd.c:701
 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
 usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554
 hub_port_connect drivers/usb/core/hub.c:5208 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
 port_event drivers/usb/core/hub.c:5494 [inline]
 hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576
 process_one_work+0x1688/0x2140 kernel/workqueue.c:2269
 worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415
 kthread+0x551/0x590 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293

Local variable ----buf.i87@smsc75xx_bind created at:
 __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
 smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
 __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
 smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482

This issue is caused because usbnet_read_cmd() reads less bytes than requested
(zero byte in the reproducer). In this case, 'buf' is not properly filled.

This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads
less bytes than requested.</Note>
    </Notes>
    <CVE>CVE-2023-52528</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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">** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2023-52575</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix deadlock or deadcode of misusing dget()

The lock order is incorrect between denty and its parent, we should
always make sure that the parent get the lock first.

But since this deadcode is never used and the parent dir will always
be set from the callers, let's just remove it.</Note>
    </Notes>
    <CVE>CVE-2023-52583</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Add mutex lock in control vblank irq

Add a mutex lock to control vblank irq to synchronize vblank
enable/disable operations happening from different threads to prevent
race conditions while registering/unregistering the vblank irq callback.

v4: -Removed vblank_ctl_lock from dpu_encoder_virt, so it is only a
    parameter of dpu_encoder_phys.
    -Switch from atomic refcnt to a simple int counter as mutex has
    now been added
v3: Mistakenly did not change wording in last version. It is done now.
v2: Slightly changed wording of commit message

Patchwork: https://patchwork.freedesktop.org/patch/571854/</Note>
    </Notes>
    <CVE>CVE-2023-52586</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ipoib: Fix mcast list locking

Releasing the `priv-&gt;lock` while iterating the `priv-&gt;multicast_list` in
`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to
remove the items while in the middle of iteration. If the mcast is removed
while the lock was dropped, the for loop spins forever resulting in a hard
lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):

    Task A (kworker/u72:2 below)       | Task B (kworker/u72:0 below)
    -----------------------------------+-----------------------------------
    ipoib_mcast_join_task(work)        | ipoib_ib_dev_flush_light(work)
      spin_lock_irq(&amp;priv-&gt;lock)       | __ipoib_ib_dev_flush(priv, ...)
      list_for_each_entry(mcast,       | ipoib_mcast_dev_flush(dev = priv-&gt;dev)
          &amp;priv-&gt;multicast_list, list) |
        ipoib_mcast_join(dev, mcast)   |
          spin_unlock_irq(&amp;priv-&gt;lock) |
                                       |   spin_lock_irqsave(&amp;priv-&gt;lock, flags)
                                       |   list_for_each_entry_safe(mcast, tmcast,
                                       |                  &amp;priv-&gt;multicast_list, list)
                                       |     list_del(&amp;mcast-&gt;list);
                                       |     list_add_tail(&amp;mcast-&gt;list, &amp;remove_list)
                                       |   spin_unlock_irqrestore(&amp;priv-&gt;lock, flags)
          spin_lock_irq(&amp;priv-&gt;lock)   |
                                       |   ipoib_mcast_remove_list(&amp;remove_list)
   (Here, `mcast` is no longer on the  |     list_for_each_entry_safe(mcast, tmcast,
    `priv-&gt;multicast_list` and we keep |                            remove_list, list)
    spinning on the `remove_list` of   |  &gt;&gt;&gt;  wait_for_completion(&amp;mcast-&gt;done)
    the other thread which is blocked  |
    and the list is still valid on     |
    it's stack.)

Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent
eventual sleeps.
Unfortunately we could not reproduce the lockup and confirm this fix but
based on the code review I think this fix should address such lockups.

crash&gt; bc 31
PID: 747      TASK: ff1c6a1a007e8000  CPU: 31   COMMAND: "kworker/u72:2"
--
    [exception RIP: ipoib_mcast_join_task+0x1b1]
    RIP: ffffffffc0944ac1  RSP: ff646f199a8c7e00  RFLAGS: 00000002
    RAX: 0000000000000000  RBX: ff1c6a1a04dc82f8  RCX: 0000000000000000
                                  work (&amp;priv-&gt;mcast_task{,.work})
    RDX: ff1c6a192d60ac68  RSI: 0000000000000286  RDI: ff1c6a1a04dc8000
           &amp;mcast-&gt;list
    RBP: ff646f199a8c7e90   R8: ff1c699980019420   R9: ff1c6a1920c9a000
    R10: ff646f199a8c7e00  R11: ff1c6a191a7d9800  R12: ff1c6a192d60ac00
                                                         mcast
    R13: ff1c6a1d82200000  R14: ff1c6a1a04dc8000  R15: ff1c6a1a04dc82d8
           dev                    priv (&amp;priv-&gt;lock)     &amp;priv-&gt;multicast_list (aka head)
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
--- &lt;NMI exception stack&gt; ---
 #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib]
 #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967

crash&gt; rx ff646f199a8c7e68
ff646f199a8c7e68:  ff1c6a1a04dc82f8 &lt;&lt;&lt; work = &amp;priv-&gt;mcast_task.work

crash&gt; list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000
(empty)

crash&gt; ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000
  mcast_task.work.func = 0xffffffffc0944910 &lt;ipoib_mcast_join_task&gt;,
  mcast_mutex.owner.counter = 0xff1c69998efec000

crash&gt; b 8
PID: 8        TASK: ff1c69998efec000  CPU: 33   COMMAND: "kworker/u72:0"
--
 #3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646
 #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib]
 #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib]
 #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib]
 #7 [ff
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-52587</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

reiserfs: Avoid touching renamed directory if parent does not change

The VFS will not be locking moved directory if its parent does not
change. Change reiserfs rename code to avoid touching renamed directory
if its parent does not change as without locking that can corrupt the
filesystem.</Note>
    </Notes>
    <CVE>CVE-2023-52591</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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: rt2x00: restart beacon queue when hardware reset

When a hardware reset is triggered, all registers are reset, so all
queues are forced to stop in hardware interface. However, mac80211
will not automatically stop the queue. If we don't manually stop the
beacon queue, the queue will be deadlocked and unable to start again.
This patch fixes the issue where Apple devices cannot connect to the
AP after calling ieee80211_restart_hw().</Note>
    </Notes>
    <CVE>CVE-2023-52595</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ptrace: handle setting of fpc register correctly

If the content of the floating point control (fpc) register of a traced
process is modified with the ptrace interface the new value is tested for
validity by temporarily loading it into the fpc register.

This may lead to corruption of the fpc register of the tracing process:
if an interrupt happens while the value is temporarily loaded into the
fpc register, and within interrupt context floating point or vector
registers are used, the current fp/vx registers are saved with
save_fpu_regs() assuming they belong to user space and will be loaded into
fp/vx registers when returning to user space.

test_fp_ctl() restores the original user space fpc register value, however
it will be discarded, when returning to user space.

In result the tracer will incorrectly continue to run with the value that
was supposed to be used for the traced process.

Fix this by saving fpu register contents with save_fpu_regs() before using
test_fp_ctl().</Note>
    </Notes>
    <CVE>CVE-2023-52598</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/mm: Fix null-pointer dereference in pgtable_cache_add

kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.</Note>
    </Notes>
    <CVE>CVE-2023-52607</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

PM / devfreq: Fix buffer overflow in trans_stat_show

Fix buffer overflow in trans_stat_show().

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

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

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

Also document in the ABI that this function can return -EFBIG error.</Note>
    </Notes>
    <CVE>CVE-2023-52614</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: disallow timeout for anonymous sets

Never used from userspace, disallow these parameters.</Note>
    </Notes>
    <CVE>CVE-2023-52620</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 online resizing failures due to oversized flex bg

When we online resize an ext4 filesystem with a oversized flexbg_size,

     mkfs.ext4 -F -G 67108864 $dev -b 4096 100M
     mount $dev $dir
     resize2fs $dev 16G

the following WARN_ON is triggered:
==================================================================
WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550
Modules linked in: sg(E)
CPU: 0 PID: 427 Comm: resize2fs Tainted: G  E  6.6.0-rc5+ #314
RIP: 0010:__alloc_pages+0x411/0x550
Call Trace:
 &lt;TASK&gt;
 __kmalloc_large_node+0xa2/0x200
 __kmalloc+0x16e/0x290
 ext4_resize_fs+0x481/0xd80
 __ext4_ioctl+0x1616/0x1d90
 ext4_ioctl+0x12/0x20
 __x64_sys_ioctl+0xf0/0x150
 do_syscall_64+0x3b/0x90
==================================================================

This is because flexbg_size is too large and the size of the new_group_data
array to be allocated exceeds MAX_ORDER. Currently, the minimum value of
MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding
maximum number of groups that can be allocated is:

 (PAGE_SIZE &lt;&lt; MAX_ORDER) / sizeof(struct ext4_new_group_data) ~ 21845

And the value that is down-aligned to the power of 2 is 16384. Therefore,
this value is defined as MAX_RESIZE_BG, and the number of groups added
each time does not exceed this value during resizing, and is added multiple
times to complete the online resizing. The difference is that the metadata
in a flex_bg may be more dispersed.</Note>
    </Notes>
    <CVE>CVE-2023-52622</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

PM / devfreq: Synchronize devfreq_monitor_[start/stop]

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

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

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

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

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

[2]

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

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

Right now it is possible to see gmap-&gt;private being zero in
kvm_s390_vsie_gmap_notifier resulting in a crash.  This is due to the
fact that we add gmap-&gt;private == kvm after creation:

static int acquire_gmap_shadow(struct kvm_vcpu *vcpu,
                               struct vsie_page *vsie_page)
{
[...]
        gmap = gmap_shadow(vcpu-&gt;arch.gmap, asce, edat);
        if (IS_ERR(gmap))
                return PTR_ERR(gmap);
        gmap-&gt;private = vcpu-&gt;kvm;

Let children inherit the private field of the parent.</Note>
    </Notes>
    <CVE>CVE-2023-52639</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled

When QoS is disabled, the queue priority value will not map to the correct
ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS
is disabled to prevent trying to stop/wake a non-existent queue and failing
to stop/wake the actual queue instantiated.

Log of issue before change (with kernel parameter qos=0):
    [  +5.112651] ------------[ cut here ]------------
    [  +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211]
    [  +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3
    [  +0.000044]  videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common
    [  +0.000055]  usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)]
    [  +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G        W  O       6.6.7 #1-NixOS
    [  +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019
    [  +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211]
    [  +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 &lt;0f&gt; 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00
    [  +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097
    [  +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000
    [  +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900
    [  +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0
    [  +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000
    [  +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40
    [  +0.000001] FS:  0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000
    [  +0.000001] CS:  0010 DS: 0
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-52644</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

aio: fix mremap after fork null-deref

Commit e4a0d3e720e7 ("aio: Make it possible to remap aio ring") introduced
a null-deref if mremap is called on an old aio mapping after fork as
mm-&gt;ioctx_table will be set to NULL.

[jmoyer@redhat.com: fix 80 column issue]</Note>
    </Notes>
    <CVE>CVE-2023-52646</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/tegra: dsi: Add missing check for of_find_device_by_node

Add check for the return value of of_find_device_by_node() and return
the error if it fails in order to avoid NULL pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2023-52650</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

NTB: fix possible name leak in ntb_register_device()

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

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

[mani: reworded commit message]</Note>
    </Notes>
    <CVE>CVE-2023-52652</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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:

SUNRPC: fix a memleak in gss_import_v2_context

The ctx-&gt;mech_used.data allocated by kmemdup is not freed in neither
gss_import_v2_context nor it only caller gss_krb5_import_sec_context,
which frees ctx on error.

Thus, this patch reform the last call of gss_import_v2_context to the
gss_krb5_import_ctx_v2, preventing the memleak while keepping the return
formation.</Note>
    </Notes>
    <CVE>CVE-2023-52653</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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:

usb: aqc111: check packet for fixup for true limit

If a device sends a packet that is inbetween 0
and sizeof(u64) the value passed to skb_trim()
as length will wrap around ending up as some very
large value.

The driver will then proceed to parse the header
located at that position, which will either oops or
process some random value.

The fix is to check against sizeof(u64) rather than
0, which the driver currently does. The issue exists
since the introduction of the driver.</Note>
    </Notes>
    <CVE>CVE-2023-52655</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: atlantic: eliminate double free in error handling logic

Driver has a logic leak in ring data allocation/free,
where aq_ring_free could be called multiple times on same ring,
if system is under stress and got memory allocation error.

Ring pointer was used as an indicator of failure, but this is
not correct since only ring data is allocated/deallocated.
Ring itself is an array member.

Changing ring allocation functions to return error code directly.
This simplifies error handling and eliminates aq_ring_free
on higher layer.</Note>
    </Notes>
    <CVE>CVE-2023-52664</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/imc-pmu: Add a null pointer check in update_events_in_group()

kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.</Note>
    </Notes>
    <CVE>CVE-2023-52675</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: LPIT: Avoid u32 multiplication overflow

In lpit_update_residency() there is a possibility of overflow
in multiplication, if tsc_khz is large enough (&gt; UINT_MAX/1000).

Change multiplication to mul_u32_u32().

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2023-52683</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-2023-52685</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/powernv: Add a null pointer check in opal_event_init()

kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.</Note>
    </Notes>
    <CVE>CVE-2023-52686</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 a double-free in si_dpm_init

When the allocation of
adev-&gt;pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,
amdgpu_free_extended_power_table is called to free some fields of adev.
However, when the control flow returns to si_dpm_sw_init, it goes to
label dpm_failed and calls si_dpm_fini, which calls
amdgpu_free_extended_power_table again and free those fields again. Thus
a double-free is triggered.</Note>
    </Notes>
    <CVE>CVE-2023-52691</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: video: check for error while searching for backlight device parent

If acpi_get_parent() called in acpi_video_dev_register_backlight()
fails, for example, because acpi_ut_acquire_mutex() fails inside
acpi_get_parent), this can lead to incorrect (uninitialized)
acpi_parent handle being passed to acpi_get_pci_dev() for detecting
the parent pci device.

Check acpi_get_parent() result and set parent device only in case of success.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2023-52693</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/powernv: Add a null pointer check in opal_powercap_init()

kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.</Note>
    </Notes>
    <CVE>CVE-2023-52696</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

calipso: fix memory leak in netlbl_calipso_add_pass()

If IPv6 support is disabled at boot (ipv6.disable=1),
the calipso_init() -&gt; netlbl_calipso_ops_register() function isn't called,
and the netlbl_calipso_ops_get() function always returns NULL.
In this case, the netlbl_calipso_add_pass() function allocates memory
for the doi_def variable but doesn't free it with the calipso_doi_free().

BUG: memory leak
unreferenced object 0xffff888011d68180 (size 64):
  comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s)
  hex dump (first 32 bytes):
    00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;...&gt;] kmalloc include/linux/slab.h:552 [inline]
    [&lt;...&gt;] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]
    [&lt;...&gt;] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111
    [&lt;...&gt;] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739
    [&lt;...&gt;] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
    [&lt;...&gt;] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800
    [&lt;...&gt;] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515
    [&lt;...&gt;] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811
    [&lt;...&gt;] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]
    [&lt;...&gt;] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339
    [&lt;...&gt;] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934
    [&lt;...&gt;] sock_sendmsg_nosec net/socket.c:651 [inline]
    [&lt;...&gt;] sock_sendmsg+0x157/0x190 net/socket.c:671
    [&lt;...&gt;] ____sys_sendmsg+0x712/0x870 net/socket.c:2342
    [&lt;...&gt;] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396
    [&lt;...&gt;] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429
    [&lt;...&gt;] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46
    [&lt;...&gt;] entry_SYSCALL_64_after_hwframe+0x61/0xc6

Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with Syzkaller

[PM: merged via the LSM tree at Jakub Kicinski request]</Note>
    </Notes>
    <CVE>CVE-2023-52698</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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/usb: kalmia: Don't pass act_len in usb_bulk_msg error path

syzbot reported that act_len in kalmia_send_init_packet() is
uninitialized when passing it to the first usb_bulk_msg error path. Jiri
Pirko noted that it's pointless to pass it in the error path, and that
the value that would be printed in the second error path would be the
value of act_len from the first call to usb_bulk_msg.[1]

With this in mind, let's just not pass act_len to the usb_bulk_msg error
paths.

1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/</Note>
    </Notes>
    <CVE>CVE-2023-52703</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sdio: fix possible resource leaks in some error paths

If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can
not release the resources, because the sdio function is not presented
in these two cases, it won't call of_node_put() or put_device().

To fix these leaks, make sdio_func_present() only control whether
device_del() needs to be called or not, then always call of_node_put()
and put_device().

In error case in sdio_init_func(), the reference of 'card-&gt;dev' is
not get, to avoid redundant put in sdio_free_func_cis(), move the
get_device() to sdio_alloc_func() and put_device() to sdio_release_func(),
it can keep the get/put function be balanced.

Without this patch, while doing fault inject test, it can get the
following leak reports, after this fix, the leak is gone.

unreferenced object 0xffff888112514000 (size 2048):
  comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s)
  hex dump (first 32 bytes):
    00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff  ..o.....`X......
    10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff  .@Q......@Q.....
  backtrace:
    [&lt;000000009e5931da&gt;] kmalloc_trace+0x21/0x110
    [&lt;000000002f839ccb&gt;] mmc_alloc_card+0x38/0xb0 [mmc_core]
    [&lt;0000000004adcbf6&gt;] mmc_sdio_init_card+0xde/0x170 [mmc_core]
    [&lt;000000007538fea0&gt;] mmc_attach_sdio+0xcb/0x1b0 [mmc_core]
    [&lt;00000000d4fdeba7&gt;] mmc_rescan+0x54a/0x640 [mmc_core]

unreferenced object 0xffff888112511000 (size 2048):
  comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s)
  hex dump (first 32 bytes):
    00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff  .@Q......X......
    10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff  ..Q.......Q.....
  backtrace:
    [&lt;000000009e5931da&gt;] kmalloc_trace+0x21/0x110
    [&lt;00000000fcbe706c&gt;] sdio_alloc_func+0x35/0x100 [mmc_core]
    [&lt;00000000c68f4b50&gt;] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core]
    [&lt;00000000d4fdeba7&gt;] mmc_rescan+0x54a/0x640 [mmc_core]</Note>
    </Notes>
    <CVE>CVE-2023-52730</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: blocklist the kclient when receiving corrupted snap trace

When received corrupted snap trace we don't know what exactly has
happened in MDS side. And we shouldn't continue IOs and metadatas
access to MDS, which may corrupt or get incorrect contents.

This patch will just block all the further IO/MDS requests
immediately and then evict the kclient itself.

The reason why we still need to evict the kclient just after
blocking all the further IOs is that the MDS could revoke the caps
faster.</Note>
    </Notes>
    <CVE>CVE-2023-52732</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: lock the inode in shared mode before starting fiemap

Currently fiemap does not take the inode's lock (VFS lock), it only locks
a file range in the inode's io tree. This however can lead to a deadlock
if we have a concurrent fsync on the file and fiemap code triggers a fault
when accessing the user space buffer with fiemap_fill_next_extent(). The
deadlock happens on the inode's i_mmap_lock semaphore, which is taken both
by fsync and btrfs_page_mkwrite(). This deadlock was recently reported by
syzbot and triggers a trace like the following:

   task:syz-executor361 state:D stack:20264 pid:5668  ppid:5119   flags:0x00004004
   Call Trace:
    &lt;TASK&gt;
    context_switch kernel/sched/core.c:5293 [inline]
    __schedule+0x995/0xe20 kernel/sched/core.c:6606
    schedule+0xcb/0x190 kernel/sched/core.c:6682
    wait_on_state fs/btrfs/extent-io-tree.c:707 [inline]
    wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751
    lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742
    find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488
    writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863
    __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174
    extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091
    extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211
    do_writepages+0x3c3/0x680 mm/page-writeback.c:2581
    filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388
    __filemap_fdatawrite_range mm/filemap.c:421 [inline]
    filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439
    btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline]
    start_ordered_ops fs/btrfs/file.c:1737 [inline]
    btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839
    generic_write_sync include/linux/fs.h:2885 [inline]
    btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684
    call_write_iter include/linux/fs.h:2189 [inline]
    new_sync_write fs/read_write.c:491 [inline]
    vfs_write+0x7dc/0xc50 fs/read_write.c:584
    ksys_write+0x177/0x2a0 fs/read_write.c:637
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
   RIP: 0033:0x7f7d4054e9b9
   RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
   RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9
   RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006
   RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000
   R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69
   R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8
    &lt;/TASK&gt;
   INFO: task syz-executor361:5697 blocked for more than 145 seconds.
         Not tainted 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0
   "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
   task:syz-executor361 state:D stack:21216 pid:5697  ppid:5119   flags:0x00004004
   Call Trace:
    &lt;TASK&gt;
    context_switch kernel/sched/core.c:5293 [inline]
    __schedule+0x995/0xe20 kernel/sched/core.c:6606
    schedule+0xcb/0x190 kernel/sched/core.c:6682
    rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095
    __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260
    btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526
    do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947
    wp_page_shared+0x15e/0x380 mm/memory.c:3295
    handle_pte_fault mm/memory.c:4949 [inline]
    __handle_mm_fault mm/memory.c:5073 [inline]
    handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219
    do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428
    handle_page_fault arch/x86/mm/fault.c:1519 [inline]
    exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575
    asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570
   RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233
   Code: 74 0a 89 (...)
   RSP: 0018:ffffc9000570f330 EFLAGS: 000502
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-52737</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use-after-free in rdata-&gt;read_into_pages()

When the network status is unstable, use-after-free may occur when
read data from the server.

  BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0

  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x38/0x4c
   print_report+0x16f/0x4a6
   kasan_report+0xb7/0x130
   readpages_fill_pages+0x14c/0x7e0
   cifs_readv_receive+0x46d/0xa40
   cifs_demultiplex_thread+0x121c/0x1490
   kthread+0x16b/0x1a0
   ret_from_fork+0x2c/0x50
   &lt;/TASK&gt;

  Allocated by task 2535:
   kasan_save_stack+0x22/0x50
   kasan_set_track+0x25/0x30
   __kasan_kmalloc+0x82/0x90
   cifs_readdata_direct_alloc+0x2c/0x110
   cifs_readdata_alloc+0x2d/0x60
   cifs_readahead+0x393/0xfe0
   read_pages+0x12f/0x470
   page_cache_ra_unbounded+0x1b1/0x240
   filemap_get_pages+0x1c8/0x9a0
   filemap_read+0x1c0/0x540
   cifs_strict_readv+0x21b/0x240
   vfs_read+0x395/0x4b0
   ksys_read+0xb8/0x150
   do_syscall_64+0x3f/0x90
   entry_SYSCALL_64_after_hwframe+0x72/0xdc

  Freed by task 79:
   kasan_save_stack+0x22/0x50
   kasan_set_track+0x25/0x30
   kasan_save_free_info+0x2e/0x50
   __kasan_slab_free+0x10e/0x1a0
   __kmem_cache_free+0x7a/0x1a0
   cifs_readdata_release+0x49/0x60
   process_one_work+0x46c/0x760
   worker_thread+0x2a4/0x6f0
   kthread+0x16b/0x1a0
   ret_from_fork+0x2c/0x50

  Last potentially related work creation:
   kasan_save_stack+0x22/0x50
   __kasan_record_aux_stack+0x95/0xb0
   insert_work+0x2b/0x130
   __queue_work+0x1fe/0x660
   queue_work_on+0x4b/0x60
   smb2_readv_callback+0x396/0x800
   cifs_abort_connection+0x474/0x6a0
   cifs_reconnect+0x5cb/0xa50
   cifs_readv_from_socket.cold+0x22/0x6c
   cifs_read_page_from_socket+0xc1/0x100
   readpages_fill_pages.cold+0x2f/0x46
   cifs_readv_receive+0x46d/0xa40
   cifs_demultiplex_thread+0x121c/0x1490
   kthread+0x16b/0x1a0
   ret_from_fork+0x2c/0x50

The following function calls will cause UAF of the rdata pointer.

readpages_fill_pages
 cifs_read_page_from_socket
  cifs_readv_from_socket
   cifs_reconnect
    __cifs_reconnect
     cifs_abort_connection
      mid-&gt;callback() --&gt; smb2_readv_callback
       queue_work(&amp;rdata-&gt;work)  # if the worker completes first,
                                 # the rdata is freed
          cifs_readv_complete
            kref_put
              cifs_readdata_release
                kfree(rdata)
 return rdata-&gt;...               # UAF in readpages_fill_pages()

Similarly, this problem also occurs in the uncache_fill_pages().

Fix this by adjusts the order of condition judgment in the return
statement.</Note>
    </Notes>
    <CVE>CVE-2023-52741</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix wrong-direction WARNING in plusb.c

The syzbot fuzzer detected a bug in the plusb network driver: A
zero-length control-OUT transfer was treated as a read instead of a
write.  In modern kernels this error provokes a WARNING:

usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0
WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411
usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
Modules linked in:
CPU: 1 PID: 4645 Comm: dhcpcd Not tainted
6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/12/2023
RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
...
Call Trace:
 &lt;TASK&gt;
 usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58
 usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
 usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153
 __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010
 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068
 pl_vendor_req drivers/net/usb/plusb.c:60 [inline]
 pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline]
 pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85
 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889
 __dev_open+0x297/0x4d0 net/core/dev.c:1417
 __dev_change_flags+0x587/0x750 net/core/dev.c:8530
 dev_change_flags+0x97/0x170 net/core/dev.c:8602
 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147
 inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979
 sock_do_ioctl+0xcc/0x230 net/socket.c:1169
 sock_ioctl+0x1f8/0x680 net/socket.c:1286
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:870 [inline]
 __se_sys_ioctl fs/ioctl.c:856 [inline]
 __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856
 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

The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and
remove the USB_DIR_IN flag.</Note>
    </Notes>
    <CVE>CVE-2023-52742</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/hfi1: Restore allocated resources on failed copyout

Fix a resource leak if an error occurs.</Note>
    </Notes>
    <CVE>CVE-2023-52747</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use-after-free bug in cifs_debug_data_proc_show()

Skip SMB sessions that are being teared down
(e.g. @ses-&gt;ses_status == SES_EXITING) in cifs_debug_data_proc_show()
to avoid use-after-free in @ses.

This fixes the following GPF when reading from /proc/fs/cifs/DebugData
while mounting and umounting

  [ 816.251274] general protection fault, probably for non-canonical
  address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI
  ...
  [  816.260138] Call Trace:
  [  816.260329]  &lt;TASK&gt;
  [  816.260499]  ? die_addr+0x36/0x90
  [  816.260762]  ? exc_general_protection+0x1b3/0x410
  [  816.261126]  ? asm_exc_general_protection+0x26/0x30
  [  816.261502]  ? cifs_debug_tcon+0xbd/0x240 [cifs]
  [  816.261878]  ? cifs_debug_tcon+0xab/0x240 [cifs]
  [  816.262249]  cifs_debug_data_proc_show+0x516/0xdb0 [cifs]
  [  816.262689]  ? seq_read_iter+0x379/0x470
  [  816.262995]  seq_read_iter+0x118/0x470
  [  816.263291]  proc_reg_read_iter+0x53/0x90
  [  816.263596]  ? srso_alias_return_thunk+0x5/0x7f
  [  816.263945]  vfs_read+0x201/0x350
  [  816.264211]  ksys_read+0x75/0x100
  [  816.264472]  do_syscall_64+0x3f/0x90
  [  816.264750]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
  [  816.265135] RIP: 0033:0x7fd5e669d381</Note>
    </Notes>
    <CVE>CVE-2023-52752</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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: Avoid NULL dereference of timing generator

[Why &amp; How]
Check whether assigned timing generator is NULL or not before
accessing its funcs to prevent NULL dereference.</Note>
    </Notes>
    <CVE>CVE-2023-52753</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: imon: fix access to invalid resource for the second interface

imon driver probes two USB interfaces, and at the probe of the second
interface, the driver assumes blindly that the first interface got
bound with the same imon driver.  It's usually true, but it's still
possible that the first interface is bound with another driver via a
malformed descriptor.  Then it may lead to a memory corruption, as
spotted by syzkaller; imon driver accesses the data from drvdata as
struct imon_context object although it's a completely different one
that was assigned by another driver.

This patch adds a sanity check -- whether the first interface is
really bound with the imon driver or not -- for avoiding the problem
above at the probe time.</Note>
    </Notes>
    <CVE>CVE-2023-52754</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential deadlock when releasing mids

All release_mid() callers seem to hold a reference of @mid so there is
no need to call kref_put(&amp;mid-&gt;refcount, __release_mid) under
@server-&gt;mid_lock spinlock.  If they don't, then an use-after-free bug
would have occurred anyways.

By getting rid of such spinlock also fixes a potential deadlock as
shown below

CPU 0                                CPU 1
------------------------------------------------------------------
cifs_demultiplex_thread()            cifs_debug_data_proc_show()
 release_mid()
  spin_lock(&amp;server-&gt;mid_lock);
                                     spin_lock(&amp;cifs_tcp_ses_lock)
				      spin_lock(&amp;server-&gt;mid_lock)
  __release_mid()
   smb2_find_smb_tcon()
    spin_lock(&amp;cifs_tcp_ses_lock) *deadlock*</Note>
    </Notes>
    <CVE>CVE-2023-52757</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-2023-52759</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

virtio-blk: fix implicit overflow on virtio_max_dma_size

The following codes have an implicit conversion from size_t to u32:
(u32)max_size = (size_t)virtio_max_dma_size(vdev);

This may lead overflow, Ex (size_t)4G -&gt; (u32)0. Once
virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX
instead.</Note>
    </Notes>
    <CVE>CVE-2023-52762</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: gspca: cpia1: shift-out-of-bounds in set_flicker

Syzkaller reported the following issue:
UBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27
shift exponent 245 is too large for 32-bit type 'int'

When the value of the variable "sd-&gt;params.exposure.gain" exceeds the
number of bits in an integer, a shift-out-of-bounds error is reported. It
is triggered because the variable "currentexp" cannot be left-shifted by
more than the number of bits in an integer. In order to avoid invalid
range during left-shift, the conditional expression is added.</Note>
    </Notes>
    <CVE>CVE-2023-52764</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

s390/dasd: protect device queue against concurrent access

In dasd_profile_start() the amount of requests on the device queue are
counted. The access to the device queue is unprotected against
concurrent access. With a lot of parallel I/O, especially with alias
devices enabled, the device queue can change while dasd_profile_start()
is accessing the queue. In the worst case this leads to a kernel panic
due to incorrect pointer accesses.

Fix this by taking the device lock before accessing the queue and
counting the requests. Additionally the check for a valid profile data
pointer can be done earlier to avoid unnecessary locking in a hot path.</Note>
    </Notes>
    <CVE>CVE-2023-52774</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: config: fix iteration issue in 'usb_get_bos_descriptor()'

The BOS descriptor defines a root descriptor and is the base descriptor for
accessing a family of related descriptors.

Function 'usb_get_bos_descriptor()' encounters an iteration issue when
skipping the 'USB_DT_DEVICE_CAPABILITY' descriptor type. This results in
the same descriptor being read repeatedly.

To address this issue, a 'goto' statement is introduced to ensure that the
pointer and the amount read is updated correctly. This ensures that the
function iterates to the next descriptor instead of reading the same
descriptor repeatedly.</Note>
    </Notes>
    <CVE>CVE-2023-52781</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: stop the device in bond_setup_by_slave()

Commit 9eed321cde22 ("net: lapbether: only support ethernet devices")
has been able to keep syzbot away from net/lapb, until today.

In the following splat [1], the issue is that a lapbether device has
been created on a bonding device without members. Then adding a non
ARPHRD_ETHER member forced the bonding master to change its type.

The fix is to make sure we call dev_close() in bond_setup_by_slave()
so that the potential linked lapbether devices (or any other devices
having assumptions on the physical device) are removed.

A similar bug has been addressed in commit 40baec225765
("bonding: fix panic on non-ARPHRD_ETHER enslave failure")

[1]
skbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0
kernel BUG at net/core/skbuff.c:192 !
Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : skb_panic net/core/skbuff.c:188 [inline]
pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202
lr : skb_panic net/core/skbuff.c:188 [inline]
lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202
sp : ffff800096a06aa0
x29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000
x26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea
x23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140
x20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100
x17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001
x14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00
x8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001
x5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c
x2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086
Call trace:
skb_panic net/core/skbuff.c:188 [inline]
skb_under_panic+0x13c/0x140 net/core/skbuff.c:202
skb_push+0xf0/0x108 net/core/skbuff.c:2446
ip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384
dev_hard_header include/linux/netdevice.h:3136 [inline]
lapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257
lapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447
lapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149
lapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251
__lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326
lapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492
notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93
raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461
call_netdevice_notifiers_info net/core/dev.c:1970 [inline]
call_netdevice_notifiers_extack net/core/dev.c:2008 [inline]
call_netdevice_notifiers net/core/dev.c:2022 [inline]
__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508
dev_close_many+0x1e0/0x470 net/core/dev.c:1559
dev_close+0x174/0x250 net/core/dev.c:1585
lapbeth_device_event+0x2e4/0x958 drivers/net/wan/lapbether.c:466
notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93
raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461
call_netdevice_notifiers_info net/core/dev.c:1970 [inline]
call_netdevice_notifiers_extack net/core/dev.c:2008 [inline]
call_netdevice_notifiers net/core/dev.c:2022 [inline]
__dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508
dev_close_many+0x1e0/0x470 net/core/dev.c:1559
dev_close+0x174/0x250 net/core/dev.c:1585
bond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332
bond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c:4539
dev_ifsioc+0x754/0x9ac
dev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786
sock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217
sock_ioctl+0x4e8/0x834 net/socket.c:1322
vfs_ioctl fs/ioctl.c:51 [inline]
__do_
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-52784</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipvlan: add ipvlan_route_v6_outbound() helper

Inspired by syzbot reports using a stack of multiple ipvlan devices.

Reduce stack size needed in ipvlan_process_v6_outbound() by moving
the flowi6 struct used for the route lookup in an non inlined
helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,
immediately reclaimed.

Also make sure ipvlan_process_v4_outbound() is not inlined.

We might also have to lower MAX_NEST_DEV, because only syzbot uses
setups with more than four stacked devices.

BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)
stack guard page: 0000 [#1] SMP KASAN
CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188
Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 &lt;41&gt; 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89
RSP: 0018:ffffc9000e804000 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2
RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568
RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c
R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000
FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
&lt;#DF&gt;
&lt;/#DF&gt;
&lt;TASK&gt;
[&lt;ffffffff81f281d1&gt;] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31
[&lt;ffffffff817e5bf2&gt;] instrument_atomic_read include/linux/instrumented.h:72 [inline]
[&lt;ffffffff817e5bf2&gt;] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
[&lt;ffffffff817e5bf2&gt;] cpumask_test_cpu include/linux/cpumask.h:506 [inline]
[&lt;ffffffff817e5bf2&gt;] cpu_online include/linux/cpumask.h:1092 [inline]
[&lt;ffffffff817e5bf2&gt;] trace_lock_acquire include/trace/events/lock.h:24 [inline]
[&lt;ffffffff817e5bf2&gt;] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632
[&lt;ffffffff8563221e&gt;] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306
[&lt;ffffffff8561464d&gt;] rcu_read_lock include/linux/rcupdate.h:747 [inline]
[&lt;ffffffff8561464d&gt;] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221
[&lt;ffffffff85618120&gt;] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606
[&lt;ffffffff856f65b5&gt;] pol_lookup_func include/net/ip6_fib.h:584 [inline]
[&lt;ffffffff856f65b5&gt;] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116
[&lt;ffffffff85618009&gt;] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638
[&lt;ffffffff8561821a&gt;] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651
[&lt;ffffffff838bd5a3&gt;] ip6_route_output include/net/ip6_route.h:100 [inline]
[&lt;ffffffff838bd5a3&gt;] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline]
[&lt;ffffffff838bd5a3&gt;] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline]
[&lt;ffffffff838bd5a3&gt;] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]
[&lt;ffffffff838bd5a3&gt;] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677
[&lt;ffffffff838c2909&gt;] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229
[&lt;ffffffff84d03900&gt;] netdev_start_xmit include/linux/netdevice.h:4966 [inline]
[&lt;ffffffff84d03900&gt;] xmit_one net/core/dev.c:3644 [inline]
[&lt;ffffffff84d03900&gt;] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660
[&lt;ffffffff84d080e2&gt;] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324
[&lt;ffffffff855ce4cd&gt;] dev_queue_xmit include/linux/netdevice.h:3067 [inline]
[&lt;ffffffff855ce4cd&gt;] neigh_hh_output include/net/neighbour.h:529 [inline]
[&lt;f
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-52796</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 RPC client cleaned up the freed pipefs dentries

RPC client pipefs dentries cleanup is in separated rpc_remove_pipedir()
workqueue,which takes care about pipefs superblock locking.
In some special scenarios, when kernel frees the pipefs sb of the
current client and immediately alloctes a new pipefs sb,
rpc_remove_pipedir function would misjudge the existence of pipefs
sb which is not the one it used to hold. As a result,
the rpc_remove_pipedir would clean the released freed pipefs dentries.

To fix this issue, rpc_remove_pipedir should check whether the
current pipefs sb is consistent with the original pipefs sb.

This error can be catched by KASAN:
=========================================================
[  250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200
[  250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503
[  250.500549] Workqueue: events rpc_free_client_work
[  250.501001] Call Trace:
[  250.502880]  kasan_report+0xb6/0xf0
[  250.503209]  ? dget_parent+0x195/0x200
[  250.503561]  dget_parent+0x195/0x200
[  250.503897]  ? __pfx_rpc_clntdir_depopulate+0x10/0x10
[  250.504384]  rpc_rmdir_depopulate+0x1b/0x90
[  250.504781]  rpc_remove_client_dir+0xf5/0x150
[  250.505195]  rpc_free_client_work+0xe4/0x230
[  250.505598]  process_one_work+0x8ee/0x13b0
...
[   22.039056] Allocated by task 244:
[   22.039390]  kasan_save_stack+0x22/0x50
[   22.039758]  kasan_set_track+0x25/0x30
[   22.040109]  __kasan_slab_alloc+0x59/0x70
[   22.040487]  kmem_cache_alloc_lru+0xf0/0x240
[   22.040889]  __d_alloc+0x31/0x8e0
[   22.041207]  d_alloc+0x44/0x1f0
[   22.041514]  __rpc_lookup_create_exclusive+0x11c/0x140
[   22.041987]  rpc_mkdir_populate.constprop.0+0x5f/0x110
[   22.042459]  rpc_create_client_dir+0x34/0x150
[   22.042874]  rpc_setup_pipedir_sb+0x102/0x1c0
[   22.043284]  rpc_client_register+0x136/0x4e0
[   22.043689]  rpc_new_client+0x911/0x1020
[   22.044057]  rpc_create_xprt+0xcb/0x370
[   22.044417]  rpc_create+0x36b/0x6c0
...
[   22.049524] Freed by task 0:
[   22.049803]  kasan_save_stack+0x22/0x50
[   22.050165]  kasan_set_track+0x25/0x30
[   22.050520]  kasan_save_free_info+0x2b/0x50
[   22.050921]  __kasan_slab_free+0x10e/0x1a0
[   22.051306]  kmem_cache_free+0xa5/0x390
[   22.051667]  rcu_core+0x62c/0x1930
[   22.051995]  __do_softirq+0x165/0x52a
[   22.052347]
[   22.052503] Last potentially related work creation:
[   22.052952]  kasan_save_stack+0x22/0x50
[   22.053313]  __kasan_record_aux_stack+0x8e/0xa0
[   22.053739]  __call_rcu_common.constprop.0+0x6b/0x8b0
[   22.054209]  dentry_free+0xb2/0x140
[   22.054540]  __dentry_kill+0x3be/0x540
[   22.054900]  shrink_dentry_list+0x199/0x510
[   22.055293]  shrink_dcache_parent+0x190/0x240
[   22.055703]  do_one_tree+0x11/0x40
[   22.056028]  shrink_dcache_for_umount+0x61/0x140
[   22.056461]  generic_shutdown_super+0x70/0x590
[   22.056879]  kill_anon_super+0x3a/0x60
[   22.057234]  rpc_kill_sb+0x121/0x200</Note>
    </Notes>
    <CVE>CVE-2023-52803</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfs

If init debugfs failed during device registration due to memory allocation
failure, debugfs_remove_recursive() is called, after which debugfs_dir is
not set to NULL. debugfs_remove_recursive() will be called again during
device removal. As a result, illegal pointer is accessed.

[ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs!
...
[ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0
[ 1669.872669] pc : down_write+0x24/0x70
[ 1669.876315] lr : down_write+0x1c/0x70
[ 1669.879961] sp : ffff000036f53a30
[ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8
[ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000
[ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270
[ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8
[ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310
[ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10
[ 1669.914982] x17: 0000000000000000 x16: 0000000000000000
[ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870
[ 1669.925555] x13: 0000000000000040 x12: 0000000000000228
[ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0
[ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10
[ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff
[ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00
[ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000
[ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001
[ 1669.962563] Call trace:
[ 1669.965000]  down_write+0x24/0x70
[ 1669.968301]  debugfs_remove_recursive+0x5c/0x1b0
[ 1669.972905]  hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main]
[ 1669.978541]  hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw]
[ 1669.984175]  pci_device_remove+0x48/0xd8
[ 1669.988082]  device_release_driver_internal+0x1b4/0x250
[ 1669.993282]  device_release_driver+0x28/0x38
[ 1669.997534]  pci_stop_bus_device+0x84/0xb8
[ 1670.001611]  pci_stop_and_remove_bus_device_locked+0x24/0x40
[ 1670.007244]  remove_store+0xfc/0x140
[ 1670.010802]  dev_attr_store+0x44/0x60
[ 1670.014448]  sysfs_kf_write+0x58/0x80
[ 1670.018095]  kernfs_fop_write+0xe8/0x1f0
[ 1670.022000]  __vfs_write+0x60/0x190
[ 1670.025472]  vfs_write+0xac/0x1c0
[ 1670.028771]  ksys_write+0x6c/0xd8
[ 1670.032071]  __arm64_sys_write+0x24/0x30
[ 1670.035977]  el0_svc_common+0x78/0x130
[ 1670.039710]  el0_svc_handler+0x38/0x78
[ 1670.043442]  el0_svc+0x8/0xc

To fix this, set debugfs_dir to NULL after debugfs_remove_recursive().</Note>
    </Notes>
    <CVE>CVE-2023-52808</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()

fc_lport_ptp_setup() did not check the return value of fc_rport_create()
which can return NULL and would cause a NULL pointer dereference. Address
this issue by checking return value of fc_rport_create() and log error
message on fc_rport_create() failed.</Note>
    </Notes>
    <CVE>CVE-2023-52809</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 SourceCodester Engineers Online Portal 1.0. It has been classified as critical. This affects an unknown part of the file remove_inbox_message.php. The manipulation of the argument id leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-240909 was assigned to this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2023-5281</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>6.5</BaseScore>
        <Vector>AV:N/AC:L/Au:S/C:P/I:P/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL

In certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:

1. Navigate to the directory: /sys/kernel/debug/dri/0
2. Execute command: cat amdgpu_regs_smc
3. Exception Log::
[4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000
[4005007.702562] #PF: supervisor instruction fetch in kernel mode
[4005007.702567] #PF: error_code(0x0010) - not-present page
[4005007.702570] PGD 0 P4D 0
[4005007.702576] Oops: 0010 [#1] SMP NOPTI
[4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G           OE     5.15.0-43-generic #46-Ubunt       u
[4005007.702590] RIP: 0010:0x0
[4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
[4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206
[4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68
[4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000
[4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980
[4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000
[4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000
[4005007.702622] FS:  00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000
[4005007.702626] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0
[4005007.702633] Call Trace:
[4005007.702636]  &lt;TASK&gt;
[4005007.702640]  amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu]
[4005007.703002]  full_proxy_read+0x5c/0x80
[4005007.703011]  vfs_read+0x9f/0x1a0
[4005007.703019]  ksys_read+0x67/0xe0
[4005007.703023]  __x64_sys_read+0x19/0x20
[4005007.703028]  do_syscall_64+0x5c/0xc0
[4005007.703034]  ? do_user_addr_fault+0x1e3/0x670
[4005007.703040]  ? exit_to_user_mode_prepare+0x37/0xb0
[4005007.703047]  ? irqentry_exit_to_user_mode+0x9/0x20
[4005007.703052]  ? irqentry_exit+0x19/0x30
[4005007.703057]  ? exc_page_fault+0x89/0x160
[4005007.703062]  ? asm_exc_page_fault+0x8/0x30
[4005007.703068]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[4005007.703075] RIP: 0033:0x7f5e07672992
[4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f        1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e       c 28 48 89 54 24
[4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992
[4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003
[4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010
[4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000
[4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000
[4005007.703105]  &lt;/TASK&gt;
[4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_       iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t       tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm       i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo       mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v       2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core        drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca
[4005007.703184] CR2: 0000000000000000
[4005007.703188] ---[ en
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-52817</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix UBSAN array-index-out-of-bounds for SMU7

For pptable structs that use flexible array sizes, use flexible arrays.</Note>
    </Notes>
    <CVE>CVE-2023-52818</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga

For pptable structs that use flexible array sizes, use flexible arrays.</Note>
    </Notes>
    <CVE>CVE-2023-52819</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/panel: fix a possible null pointer dereference

In versatile_panel_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-2023-52821</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: don't return unset power in ieee80211_get_tx_power()

We can get a UBSAN warning if ieee80211_get_tx_power() returns the
INT_MIN value mac80211 internally uses for "unset power level".

 UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5
 -2147483648 * 100 cannot be represented in type 'int'
 CPU: 0 PID: 20433 Comm: insmod Tainted: G        WC OE
 Call Trace:
  dump_stack+0x74/0x92
  ubsan_epilogue+0x9/0x50
  handle_overflow+0x8d/0xd0
  __ubsan_handle_mul_overflow+0xe/0x10
  nl80211_send_iface+0x688/0x6b0 [cfg80211]
  [...]
  cfg80211_register_wdev+0x78/0xb0 [cfg80211]
  cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211]
  [...]
  ieee80211_if_add+0x60e/0x8f0 [mac80211]
  ieee80211_register_hw+0xda5/0x1170 [mac80211]

In this case, simply return an error instead, to indicate
that no data is available.</Note>
    </Notes>
    <CVE>CVE-2023-52832</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

atl1c: Work around the DMA RX overflow issue

This is based on alx driver commit 881d0327db37 ("net: alx: Work around
the DMA RX overflow issue").

The alx and atl1c drivers had RX overflow error which was why a custom
allocator was created to avoid certain addresses. The simpler workaround
then created for alx driver, but not for atl1c due to lack of tester.

Instead of using a custom allocator, check the allocated skb address and
use skb_reserve() to move away from problematic 0x...fc0 address.

Tested on AR8131 on Acer 4540.</Note>
    </Notes>
    <CVE>CVE-2023-52834</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

perf/core: Bail out early if the request AUX area is out of bound

When perf-record with a large AUX area, e.g 4GB, it fails with:

    #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
    failed to mmap with 12 (Cannot allocate memory)

and it reveals a WARNING with __alloc_pages():

	------------[ cut here ]------------
	WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248
	Call trace:
	 __alloc_pages+0x1ec/0x248
	 __kmalloc_large_node+0xc0/0x1f8
	 __kmalloc_node+0x134/0x1e8
	 rb_alloc_aux+0xe0/0x298
	 perf_mmap+0x440/0x660
	 mmap_region+0x308/0x8a8
	 do_mmap+0x3c0/0x528
	 vm_mmap_pgoff+0xf4/0x1b8
	 ksys_mmap_pgoff+0x18c/0x218
	 __arm64_sys_mmap+0x38/0x58
	 invoke_syscall+0x50/0x128
	 el0_svc_common.constprop.0+0x58/0x188
	 do_el0_svc+0x34/0x50
	 el0_svc+0x34/0x108
	 el0t_64_sync_handler+0xb8/0xc0
	 el0t_64_sync+0x1a4/0x1a8

'rb-&gt;aux_pages' allocated by kcalloc() is a pointer array which is used to
maintains AUX trace pages. The allocated page for this array is physically
contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the
size of pointer array crosses the limitation set by MAX_ORDER, it reveals a
WARNING.

So bail out early with -ENOMEM if the request AUX area is out of bound,
e.g.:

    #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
    failed to mmap with 12 (Cannot allocate memory)</Note>
    </Notes>
    <CVE>CVE-2023-52835</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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:

llc: verify mac len before reading mac header

LLC reads the mac header with eth_hdr without verifying that the skb
has an Ethernet header.

Syzbot was able to enter llc_rcv on a tun device. Tun can insert
packets without mac len and with user configurable skb-&gt;protocol
(passing a tun_pi header when not configuring IFF_NO_PI).

    BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
    BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
    llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
    llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
    llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218
    __netif_receive_skb_one_core net/core/dev.c:5523 [inline]
    __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637
    netif_receive_skb_internal net/core/dev.c:5723 [inline]
    netif_receive_skb+0x58/0x660 net/core/dev.c:5782
    tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
    tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002

Add a mac_len test before all three eth_hdr(skb) calls under net/llc.

There are further uses in include/net/llc_pdu.h. All these are
protected by a test skb-&gt;protocol == ETH_P_802_2. Which does not
protect against this tun scenario.

But the mac_len test added in this patch in llc_fixup_skb will
indirectly protect those too. That is called from llc_rcv before any
other LLC code.

It is tempting to just add a blanket mac_len check in llc_rcv, but
not sure whether that could break valid LLC paths that do not assume
an Ethernet header. 802.2 LLC may be used on top of non-802.3
protocols in principle. The below referenced commit shows that used
to, on top of Token Ring.

At least one of the three eth_hdr uses goes back to before the start
of git history. But the one that syzbot exercises is introduced in
this commit. That commit is old enough (2008), that effectively all
stable kernels should receive this.</Note>
    </Notes>
    <CVE>CVE-2023-52843</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Change nla_policy for bearer-related names to NLA_NUL_STRING

syzbot reported the following uninit-value access issue [1]:

=====================================================
BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]
BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756
 strlen lib/string.c:418 [inline]
 strstr+0xb8/0x2f0 lib/string.c:756
 tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595
 genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]
 genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]
 genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066
 netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545
 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075
 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
 netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368
 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
 sock_sendmsg_nosec net/socket.c:730 [inline]
 sock_sendmsg net/socket.c:753 [inline]
 ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
 __sys_sendmsg net/socket.c:2624 [inline]
 __do_sys_sendmsg net/socket.c:2633 [inline]
 __se_sys_sendmsg net/socket.c:2631 [inline]
 __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Uninit was created at:
 slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767
 slab_alloc_node mm/slub.c:3478 [inline]
 kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523
 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559
 __alloc_skb+0x318/0x740 net/core/skbuff.c:650
 alloc_skb include/linux/skbuff.h:1286 [inline]
 netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]
 netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885
 sock_sendmsg_nosec net/socket.c:730 [inline]
 sock_sendmsg net/socket.c:753 [inline]
 ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
 __sys_sendmsg net/socket.c:2624 [inline]
 __do_sys_sendmsg net/socket.c:2633 [inline]
 __se_sys_sendmsg net/socket.c:2631 [inline]
 __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

TIPC bearer-related names including link names must be null-terminated
strings. If a link name which is not null-terminated is passed through
netlink, strstr() and similar functions can cause buffer overrun. This
causes the above issue.

This patch changes the nla_policy for bearer-related names from NLA_STRING
to NLA_NUL_STRING. This resolves the issue by ensuring that only
null-terminated strings are accepted as bearer-related names.

syzbot reported similar uninit-value issue related to bearer names [2]. The
root cause of this issue is that a non-null-terminated bearer name was
passed. This patch also resolved this issue.</Note>
    </Notes>
    <CVE>CVE-2023-52845</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dwc2: fix possible NULL pointer dereference caused by driver concurrency

In _dwc2_hcd_urb_enqueue(), "urb-&gt;hcpriv = NULL" is executed without
holding the lock "hsotg-&gt;lock". In _dwc2_hcd_urb_dequeue():

    spin_lock_irqsave(&amp;hsotg-&gt;lock, flags);
    ...
	if (!urb-&gt;hcpriv) {
		dev_dbg(hsotg-&gt;dev, "## urb-&gt;hcpriv is NULL ##\n");
		goto out;
	}
    rc = dwc2_hcd_urb_dequeue(hsotg, urb-&gt;hcpriv); // Use urb-&gt;hcpriv
    ...
out:
    spin_unlock_irqrestore(&amp;hsotg-&gt;lock, flags);

When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are
concurrently executed, the NULL check of "urb-&gt;hcpriv" can be executed
before "urb-&gt;hcpriv = NULL". After urb-&gt;hcpriv is NULL, it can be used
in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL
pointer dereference.

This possible bug is found by an experimental static analysis tool
developed by myself. This tool analyzes the locking APIs to extract
function pairs that can be concurrently executed, and then analyzes the
instructions in the paired functions to identify possible concurrency
bugs including data races and atomicity violations. The above possible
bug is reported, when my tool analyzes the source code of Linux 6.5.

To fix this possible bug, "urb-&gt;hcpriv = NULL" should be executed with
holding the lock "hsotg-&gt;lock". After using this patch, my tool never
reports the possible bug, with the kernelconfiguration allyesconfig for
x86_64. Because I have no associated hardware, I cannot test the patch
in runtime testing, and just verify it according to the code logic.</Note>
    </Notes>
    <CVE>CVE-2023-52855</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: wmi: Fix opening of char device

Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via
file private data"), the miscdevice stores a pointer to itself inside
filp-&gt;private_data, which means that private_data will not be NULL when
wmi_char_open() is called. This might cause memory corruption should
wmi_char_open() be unable to find its driver, something which can
happen when the associated WMI device is deleted in wmi_free_devices().

Fix the problem by using the miscdevice pointer to retrieve the WMI
device data associated with a char device using container_of(). This
also avoids wmi_char_open() picking a wrong WMI device bound to a
driver with the same name as the original driver.</Note>
    </Notes>
    <CVE>CVE-2023-52864</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data

Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2023-52865</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: possible buffer overflow

Buffer 'afmt_status' of size 6 could overflow, since index 'afmt_idx' is
checked after access.</Note>
    </Notes>
    <CVE>CVE-2023-52867</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data

Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2023-52875</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: require CAP_NET_ADMIN to attach N_GSM0710 ldisc

Any unprivileged user can attach N_GSM0710 ldisc, but it requires
CAP_NET_ADMIN to create a GSM network anyway.

Require initial namespace CAP_NET_ADMIN to do that.</Note>
    </Notes>
    <CVE>CVE-2023-52880</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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:

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-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">NSS was susceptible to a timing side-channel attack when performing RSA decryption. This attack could potentially allow an attacker to recover the private data. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.</Note>
    </Notes>
    <CVE>CVE-2023-5388</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:mozilla-nss-certs-3.101.1-58.118.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver and causing kernel panic and a denial of service.</Note>
    </Notes>
    <CVE>CVE-2023-6356</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service.</Note>
    </Notes>
    <CVE>CVE-2023-6535</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was found in the CPython `tempfile.TemporaryDirectory` class affecting versions 3.12.1, 3.11.7, 3.10.13, 3.9.18, and 3.8.18 and prior.

The tempfile.TemporaryDirectory class would dereference symlinks during cleanup of permissions-related errors. This means users which can run privileged programs are potentially able to modify permissions of files referenced by symlinks in some circumstances.
</Note>
    </Notes>
    <CVE>CVE-2023-6597</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service.</Note>
    </Notes>
    <CVE>CVE-2023-7042</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 memory leak problem was found in ctnetlink_create_conntrack in net/netfilter/nf_conntrack_netlink.c in the Linux Kernel. This issue may allow a local attacker with CAP_NET_ADMIN privileges to cause a denial of service (DoS) attack due to a refcount overflow.</Note>
    </Notes>
    <CVE>CVE-2023-7192</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 defect was discovered in the Python "ssl" module where there is a memory
race condition with the ssl.SSLContext methods "cert_store_stats()" and
"get_ca_certs()". The race condition can be triggered if the methods are
called at the same time as certificates are loaded into the SSLContext,
such as during the TLS handshake with a certificate directory configured.
This issue is fixed in CPython 3.10.14, 3.11.9, 3.12.3, and 3.13.0a5.</Note>
    </Notes>
    <CVE>CVE-2024-0397</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was found in the CPython `zipfile` module affecting versions 3.12.1, 3.11.7, 3.10.13, 3.9.18, and 3.8.18 and prior.

The zipfile module is vulnerable to "quoted-overlap" zip-bombs which exploit the zip format to create a zip-bomb with a high compression ratio. The fixed versions of CPython makes the zipfile module reject zip archives which overlap entries in the archive.

</Note>
    </Notes>
    <CVE>CVE-2024-0450</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libpython2_7-1_0-2.7.18-33.35.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libpython3_4m1_0-3.4.10-25.130.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-2.7.18-33.35.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-base-2.7.18-33.35.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-xml-2.7.18-33.35.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python3-3.4.10-25.130.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python3-base-3.4.10-25.130.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A denial of service vulnerability due to a deadlock was found in sctp_auto_asconf_init in net/sctp/socket.c in the Linux kernel's SCTP subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.</Note>
    </Notes>
    <CVE>CVE-2024-0639</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 cross-privilege Spectre v2 vulnerability allows attackers to bypass all deployed mitigations, including the recent Fine(IBT), and to leak arbitrary Linux kernel memory on Intel systems.</Note>
    </Notes>
    <CVE>CVE-2024-2201</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">NULL Pointer Dereference vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (net, bluetooth modules) allows Overflow Buffers. This vulnerability is associated with program files /net/bluetooth/rfcomm/core.C.

This issue affects Linux kernel: v2.6.12-rc2.

</Note>
    </Notes>
    <CVE>CVE-2024-22099</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow.</Note>
    </Notes>
    <CVE>CVE-2024-23307</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel through 6.7.1, there is a use-after-free in cec_queue_msg_fh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c.</Note>
    </Notes>
    <CVE>CVE-2024-23848</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 race condition was found in the Linux kernel's scsi device driver in lpfc_unregister_fcf_rescan() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.




</Note>
    </Notes>
    <CVE>CVE-2024-24855</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 race condition was found in the Linux kernel's media/xc4000 device driver in xc4000 xc4000_get_frequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.




</Note>
    </Notes>
    <CVE>CVE-2024-24861</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: make sure init the accept_queue's spinlocks once

When I run syz's reproduction C program locally, it causes the following
issue:
pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!
WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7
30 20 ce 8f e8 ad 56 42 ff &lt;0f&gt; 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900
RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff
R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000
R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000
FS:  00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0
Call Trace:
&lt;IRQ&gt;
  _raw_spin_unlock (kernel/locking/spinlock.c:186)
  inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)
  inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358)
  tcp_check_req (net/ipv4/tcp_minisocks.c:868)
  tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260)
  ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)
  ip_local_deliver_finish (net/ipv4/ip_input.c:234)
  __netif_receive_skb_one_core (net/core/dev.c:5529)
  process_backlog (./include/linux/rcupdate.h:779)
  __napi_poll (net/core/dev.c:6533)
  net_rx_action (net/core/dev.c:6604)
  __do_softirq (./arch/x86/include/asm/jump_label.h:27)
  do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)
&lt;/IRQ&gt;
&lt;TASK&gt;
  __local_bh_enable_ip (kernel/softirq.c:381)
  __dev_queue_xmit (net/core/dev.c:4374)
  ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235)
  __ip_queue_xmit (net/ipv4/ip_output.c:535)
  __tcp_transmit_skb (net/ipv4/tcp_output.c:1462)
  tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)
  tcp_rcv_state_process (net/ipv4/tcp_input.c:6657)
  tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929)
  __release_sock (./include/net/sock.h:1121 net/core/sock.c:2968)
  release_sock (net/core/sock.c:3536)
  inet_wait_for_connect (net/ipv4/af_inet.c:609)
  __inet_stream_connect (net/ipv4/af_inet.c:702)
  inet_stream_connect (net/ipv4/af_inet.c:748)
  __sys_connect (./include/linux/file.h:45 net/socket.c:2064)
  __x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070)
  do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82)
  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
  RIP: 0033:0x7fa10ff05a3d
  Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89
  c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48
  RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a
  RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d
  RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003
  RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640
  R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20
&lt;/TASK&gt;

The issue triggering process is analyzed as follows:
Thread A                                       Thread B
tcp_v4_rcv	//receive ack TCP packet       inet_shutdown
  tcp_check_req                                  tcp_disconnect //disconnect sock
  ...                                              tcp_set_state(sk, TCP_CLOSE)
    inet_csk_complete_hashdance                ...
      inet_csk_reqsk_queue_add         
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26614</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

llc: call sock_orphan() at release time

syzbot reported an interesting trace [1] caused by a stale sk-&gt;sk_wq
pointer in a closed llc socket.

In commit ff7b11aa481f ("net: socket: set sock-&gt;sk to NULL after
calling proto_ops::release()") Eric Biggers hinted that some protocols
are missing a sock_orphan(), we need to perform a full audit.

In net-next, I plan to clear sock-&gt;sk from sock_orphan() and
amend Eric patch to add a warning.

[1]
 BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline]
 BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline]
 BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline]
 BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27

CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
  print_address_description mm/kasan/report.c:377 [inline]
  print_report+0xc4/0x620 mm/kasan/report.c:488
  kasan_report+0xda/0x110 mm/kasan/report.c:601
  list_empty include/linux/list.h:373 [inline]
  waitqueue_active include/linux/wait.h:127 [inline]
  sock_def_write_space_wfree net/core/sock.c:3384 [inline]
  sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
  skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080
  skb_release_all net/core/skbuff.c:1092 [inline]
  napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404
  e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970
  e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline]
  e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801
  __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576
  napi_poll net/core/dev.c:6645 [inline]
  net_rx_action+0x956/0xe90 net/core/dev.c:6778
  __do_softirq+0x21a/0x8de kernel/softirq.c:553
  run_ksoftirqd kernel/softirq.c:921 [inline]
  run_ksoftirqd+0x31/0x60 kernel/softirq.c:913
  smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164
  kthread+0x2c6/0x3a0 kernel/kthread.c:388
  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
  ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242
 &lt;/TASK&gt;

Allocated by task 5167:
  kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
  kasan_save_track+0x14/0x30 mm/kasan/common.c:68
  unpoison_slab_object mm/kasan/common.c:314 [inline]
  __kasan_slab_alloc+0x81/0x90 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_lru+0x142/0x6f0 mm/slub.c:3879
  alloc_inode_sb include/linux/fs.h:3019 [inline]
  sock_alloc_inode+0x25/0x1c0 net/socket.c:308
  alloc_inode+0x5d/0x220 fs/inode.c:260
  new_inode_pseudo+0x16/0x80 fs/inode.c:1005
  sock_alloc+0x40/0x270 net/socket.c:634
  __sock_create+0xbc/0x800 net/socket.c:1535
  sock_create net/socket.c:1622 [inline]
  __sys_socket_create net/socket.c:1659 [inline]
  __sys_socket+0x14c/0x260 net/socket.c:1706
  __do_sys_socket net/socket.c:1720 [inline]
  __se_sys_socket net/socket.c:1718 [inline]
  __x64_sys_socket+0x72/0xb0 net/socket.c:1718
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Freed by task 0:
  kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
  kasan_save_track+0x14/0x30 mm/kasan/common.c:68
  kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
  poison_slab_object mm/kasan/common.c:241 [inline]
  __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257
  kasan_slab_free include/linux/kasan.h:184 [inline]
  slab_free_hook mm/slub.c:2121 [inlin
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26625</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()

syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.

Reading frag_off can only be done if we pulled enough bytes
to skb-&gt;head. Currently we might access garbage.

[1]
BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
__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+0x247/0xa10 net/core/dev.c:3564
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
neigh_output include/net/neighbour.h:542 [inline]
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
dst_output include/net/dst.h:451 [inline]
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
____sys_sendmsg+0x9c2/0xd60 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/0x490 net/socket.c:2674
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b

Uninit was created at:
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
slab_alloc_node mm/slub.c:3478 [inline]
__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
__do_kmalloc_node mm/slab_common.c:1006 [inline]
__kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027
kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582
pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098
__pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655
pskb_may_pull_reason include/linux/skbuff.h:2673 [inline]
pskb_may_pull include/linux/skbuff.h:2681 [inline]
ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
__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+0x247/0xa10 net/core/dev.c:3564
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
neigh_output include/net/neighbour.h:542 [inline]
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
dst_output include/net/dst.h:451 [inline]
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
__sys_sendmsg net/socket.c:2667 [inline]
__do_sys_sendms
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26633</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

llc: Drop support for ETH_P_TR_802_2.

syzbot reported an uninit-value bug below. [0]

llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2
(0x0011), and syzbot abused the latter to trigger the bug.

  write$tun(r0, &amp;(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)

llc_conn_handler() initialises local variables {saddr,daddr}.mac
based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes
them to __llc_lookup().

However, the initialisation is done only when skb-&gt;protocol is
htons(ETH_P_802_2), otherwise, __llc_lookup_established() and
__llc_lookup_listener() will read garbage.

The missing initialisation existed prior to commit 211ed865108e
("net: delete all instances of special processing for token ring").

It removed the part to kick out the token ring stuff but forgot to
close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().

Let's remove llc_tr_packet_type and complete the deprecation.

[0]:
BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90
 __llc_lookup_established+0xe9d/0xf90
 __llc_lookup net/llc/llc_conn.c:611 [inline]
 llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791
 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
 __netif_receive_skb_one_core net/core/dev.c:5527 [inline]
 __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641
 netif_receive_skb_internal net/core/dev.c:5727 [inline]
 netif_receive_skb+0x58/0x660 net/core/dev.c:5786
 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
 call_write_iter include/linux/fs.h:2020 [inline]
 new_sync_write fs/read_write.c:491 [inline]
 vfs_write+0x8ef/0x1490 fs/read_write.c:584
 ksys_write+0x20f/0x4c0 fs/read_write.c:637
 __do_sys_write fs/read_write.c:649 [inline]
 __se_sys_write fs/read_write.c:646 [inline]
 __x64_sys_write+0x93/0xd0 fs/read_write.c:646
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Local variable daddr created at:
 llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783
 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206

CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023</Note>
    </Notes>
    <CVE>CVE-2024-26635</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

llc: make llc_ui_sendmsg() more robust against bonding changes

syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no
headroom, but subsequently trying to push 14 bytes of Ethernet header [1]

Like some others, llc_ui_sendmsg() releases the socket lock before
calling sock_alloc_send_skb().
Then it acquires it again, but does not redo all the sanity checks
that were performed.

This fix:

- Uses LL_RESERVED_SPACE() to reserve space.
- Check all conditions again after socket lock is held again.
- Do not account Ethernet header for mtu limitation.

[1]

skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0

 kernel BUG at net/core/skbuff.c:193 !
Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : skb_panic net/core/skbuff.c:189 [inline]
 pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
 lr : skb_panic net/core/skbuff.c:189 [inline]
 lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
sp : ffff800096f97000
x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000
x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2
x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0
x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce
x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001
x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400
x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714
x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089
Call trace:
  skb_panic net/core/skbuff.c:189 [inline]
  skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
  skb_push+0xf0/0x108 net/core/skbuff.c:2451
  eth_header+0x44/0x1f8 net/ethernet/eth.c:83
  dev_hard_header include/linux/netdevice.h:3188 [inline]
  llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33
  llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85
  llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]
  llc_sap_next_state net/llc/llc_sap.c:182 [inline]
  llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209
  llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270
  llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg net/socket.c:745 [inline]
  sock_sendmsg+0x194/0x274 net/socket.c:767
  splice_to_socket+0x7cc/0xd58 fs/splice.c:881
  do_splice_from fs/splice.c:933 [inline]
  direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142
  splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088
  do_splice_direct+0x20c/0x348 fs/splice.c:1194
  do_sendfile+0x4bc/0xc70 fs/read_write.c:1254
  __do_sys_sendfile64 fs/read_write.c:1322 [inline]
  __se_sys_sendfile64 fs/read_write.c:1308 [inline]
  __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308
  __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
  invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
  el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
  do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
  el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678
  el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696
  el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595
Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)</Note>
    </Notes>
    <CVE>CVE-2024-26636</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()

syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].

Call pskb_inet_may_pull() to fix this, and initialize ipv6h
variable after this call as it can change skb-&gt;head.

[1]
 BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
 BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
 BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
  __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
  INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
  IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
  ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727
  __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845
  ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888
 gre_rcv+0x143f/0x1870
  ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438
  ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
  ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586
  dst_input include/net/dst.h:461 [inline]
  ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310
  __netif_receive_skb_one_core net/core/dev.c:5532 [inline]
  __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646
  netif_receive_skb_internal net/core/dev.c:5732 [inline]
  netif_receive_skb+0x58/0x660 net/core/dev.c:5791
  tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
  tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
  call_write_iter include/linux/fs.h:2084 [inline]
  new_sync_write fs/read_write.c:497 [inline]
  vfs_write+0x786/0x1200 fs/read_write.c:590
  ksys_write+0x20f/0x4c0 fs/read_write.c:643
  __do_sys_write fs/read_write.c:655 [inline]
  __se_sys_write fs/read_write.c:652 [inline]
  __x64_sys_write+0x93/0xd0 fs/read_write.c:652
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Uninit was created at:
  slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
  slab_alloc_node mm/slub.c:3478 [inline]
  kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
  __alloc_skb+0x318/0x740 net/core/skbuff.c:651
  alloc_skb include/linux/skbuff.h:1286 [inline]
  alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
  sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787
  tun_alloc_skb drivers/net/tun.c:1531 [inline]
  tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846
  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
  call_write_iter include/linux/fs.h:2084 [inline]
  new_sync_write fs/read_write.c:497 [inline]
  vfs_write+0x786/0x1200 fs/read_write.c:590
  ksys_write+0x20f/0x4c0 fs/read_write.c:643
  __do_sys_write fs/read_write.c:655 [inline]
  __se_sys_write fs/read_write.c:652 [inline]
  __x64_sys_write+0x93/0xd0 fs/read_write.c:652
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023</Note>
    </Notes>
    <CVE>CVE-2024-26641</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: disallow anonymous set with timeout flag

Anonymous sets are never used with timeout from userspace, reject this.
Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.</Note>
    </Notes>
    <CVE>CVE-2024-26642</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sr9800: Add check for usbnet_get_endpoints

Add check for usbnet_get_endpoints() and return the error if it fails
in order to transfer the error.</Note>
    </Notes>
    <CVE>CVE-2024-26651</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

blk-mq: fix IO hang from sbitmap wakeup race

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

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

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

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

Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which
is just fine in case of running out of tag.</Note>
    </Notes>
    <CVE>CVE-2024-26671</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ppp_async: limit MRU to 64K

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

WARN_ON_ONCE_GFP(order &gt; MAX_PAGE_ORDER, gfp)

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

Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU)

[1]:

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

inet_recv_error() is called without holding the socket lock.

IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM
socket option and trigger a KCSAN warning.</Note>
    </Notes>
    <CVE>CVE-2024-26679</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xen/events: close evtchn after mapping cleanup

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

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

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

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

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

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

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

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

In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was
caught by KASAN at this line - 'ceph_buffer_get(arg-&gt;xattr_buf);'. This
implies before the refcount could be increment here, it was freed.

In same file, in "handle_cap_grant()" refcount is decremented by this
line - 'ceph_buffer_put(ci-&gt;i_xattrs.blob);'. It appears that a race
occurred and resource was freed by the latter line before the former
line could increment it.

encode_cap_msg() is called by __send_cap() and __send_cap() is called by
ceph_check_caps() after calling __prep_cap(). __prep_cap() is where
arg-&gt;xattr_buf is assigned to ci-&gt;i_xattrs.blob. This is the spot where
the refcount must be increased to prevent "use after free" error.</Note>
    </Notes>
    <CVE>CVE-2024-26689</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-free of blocks due to wrong extents moved_len

In ext4_move_extents(), moved_len is only updated when all moves are
successfully executed, and only discards orig_inode and donor_inode
preallocations when moved_len is not zero. When the loop fails to exit
after successfully moving some extents, moved_len is not updated and
remains at 0, so it does not discard the preallocations.

If the moved extents overlap with the preallocated extents, the
overlapped extents are freed twice in ext4_mb_release_inode_pa() and
ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4:
Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is
incremented twice. Hence when trim is executed, a zero-division bug is
triggered in mb_update_avg_fragment_size() because bb_free is not zero
and bb_fragments is zero.

Therefore, update move_len after each extent move to avoid the issue.</Note>
    </Notes>
    <CVE>CVE-2024-26704</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-26720</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arp: Prevent overflow in arp_req_get().

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

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

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

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

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

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

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

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

If we're redirecting the skb, and haven't called tcf_mirred_forward(),
yet, we need to tell the core to drop the skb by setting the retcode
to SHOT. If we have called tcf_mirred_forward(), however, the skb
is out of our hands and returning SHOT will lead to UaF.

Move the retval override to the error path which actually need it.</Note>
    </Notes>
    <CVE>CVE-2024-26739</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/qedr: Fix qedr_create_user_qp error flow

Avoid the following warning by making sure to free the allocated
resources in case that qedr_init_user_queue() fail.

-----------[ cut here ]-----------
WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3
ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]
CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1
Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022
RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 &lt;0f&gt; 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff
RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286
RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016
RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80
R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0
Call Trace:
&lt;TASK&gt;
? show_trace_log_lvl+0x1c4/0x2df
? show_trace_log_lvl+0x1c4/0x2df
? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
? __warn+0x81/0x110
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
? report_bug+0x10a/0x140
? handle_bug+0x3c/0x70
? exc_invalid_op+0x14/0x70
? asm_exc_invalid_op+0x16/0x20
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
__fput+0x94/0x250
task_work_run+0x5c/0x90
do_exit+0x270/0x4a0
do_group_exit+0x2d/0x90
get_signal+0x87c/0x8c0
arch_do_signal_or_restart+0x25/0x100
? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]
exit_to_user_mode_loop+0x9c/0x130
exit_to_user_mode_prepare+0xb6/0x100
syscall_exit_to_user_mode+0x12/0x40
do_syscall_64+0x69/0x90
? syscall_exit_work+0x103/0x130
? syscall_exit_to_user_mode+0x22/0x40
? do_syscall_64+0x69/0x90
? syscall_exit_work+0x103/0x130
? syscall_exit_to_user_mode+0x22/0x40
? do_syscall_64+0x69/0x90
? do_syscall_64+0x69/0x90
? common_interrupt+0x43/0xa0
entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x1470abe3ec6b
Code: Unable to access opcode bytes at RIP 0x1470abe3ec41.
RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b
RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004
RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00
R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358
R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470
&lt;/TASK&gt;
--[ end trace 888a9b92e04c5c97 ]--</Note>
    </Notes>
    <CVE>CVE-2024-26743</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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:

RDMA/srpt: Support specifying the srpt_service_guid parameter

Make loading ib_srpt with this parameter set work. The current behavior is
that setting that parameter while loading the ib_srpt kernel module
triggers the following kernel crash:

BUG: kernel NULL pointer dereference, address: 0000000000000000
Call Trace:
 &lt;TASK&gt;
 parse_one+0x18c/0x1d0
 parse_args+0xe1/0x230
 load_module+0x8de/0xa60
 init_module_from_file+0x8b/0xd0
 idempotent_init_module+0x181/0x240
 __x64_sys_finit_module+0x5a/0xb0
 do_syscall_64+0x5f/0xe0
 entry_SYSCALL_64_after_hwframe+0x6e/0x76</Note>
    </Notes>
    <CVE>CVE-2024-26744</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: roles: fix NULL pointer issue when put module's reference

In current design, usb role class driver will get usb_role_switch parent's
module reference after the user get usb_role_switch device and put the
reference after the user put the usb_role_switch device. However, the
parent device of usb_role_switch may be removed before the user put the
usb_role_switch. If so, then, NULL pointer issue will be met when the user
put the parent module's reference.

This will save the module pointer in structure of usb_role_switch. Then,
we don't need to find module by iterating long relations.</Note>
    </Notes>
    <CVE>CVE-2024-26747</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

l2tp: pass correct message length to ip6_append_data

l2tp_ip6_sendmsg needs to avoid accounting for the transport header
twice when splicing more data into an already partially-occupied skbuff.

To manage this, we check whether the skbuff contains data using
skb_queue_empty when deciding how much data to append using
ip6_append_data.

However, the code which performed the calculation was incorrect:

     ulen = len + skb_queue_empty(&amp;sk-&gt;sk_write_queue) ? transhdrlen : 0;

...due to C operator precedence, this ends up setting ulen to
transhdrlen for messages with a non-zero length, which results in
corrupted packets on the wire.

Add parentheses to correct the calculation in line with the original
intent.</Note>
    </Notes>
    <CVE>CVE-2024-26752</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-crypt: don't modify the data when using authenticated encryption

It was said that authenticated encryption could produce invalid tag when
the data that is being encrypted is modified [1]. So, fix this problem by
copying the data into the clone bio first and then encrypt them inside the
clone bio.

This may reduce performance, but it is needed to prevent the user from
corrupting the device by writing data with O_DIRECT and modifying them at
the same time.

[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/</Note>
    </Notes>
    <CVE>CVE-2024-26763</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dmaengine: ti: edma: Add some null pointer checks to the edma_probe

devm_kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.</Note>
    </Notes>
    <CVE>CVE-2024-26771</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()

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

ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()

Determine if the group block bitmap is corrupted before using ac_b_ex in
ext4_mb_try_best_found() to avoid allocating blocks from a group with a
corrupted block bitmap in the following concurrency and making the
situation worse.

ext4_mb_regular_allocator
  ext4_lock_group(sb, group)
  ext4_mb_good_group
   // check if the group bbitmap is corrupted
  ext4_mb_complex_scan_group
   // Scan group gets ac_b_ex but doesn't use it
  ext4_unlock_group(sb, group)
                           ext4_mark_group_bitmap_corrupted(group)
                           // The block bitmap was corrupted during
                           // the group unlock gap.
  ext4_mb_try_best_found
    ext4_lock_group(ac-&gt;ac_sb, group)
    ext4_mb_use_best_found
      mb_mark_used
      // Allocating blocks in block bitmap corrupted group</Note>
    </Notes>
    <CVE>CVE-2024-26773</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

aoe: avoid potential deadlock at set_capacity

Move set_capacity() outside of the section procected by (&amp;d-&gt;lock).
To avoid possible interrupt unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
[1] lock(&amp;bdev-&gt;bd_size_lock);
                                local_irq_disable();
                            [2] lock(&amp;d-&gt;lock);
                            [3] lock(&amp;bdev-&gt;bd_size_lock);
   &lt;Interrupt&gt;
[4]  lock(&amp;d-&gt;lock);

  *** DEADLOCK ***

Where [1](&amp;bdev-&gt;bd_size_lock) hold by zram_add()-&gt;set_capacity().
[2]lock(&amp;d-&gt;lock) hold by aoeblk_gdalloc(). And aoeblk_gdalloc()
is trying to acquire [3](&amp;bdev-&gt;bd_size_lock) at set_capacity() call.
In this situation an attempt to acquire [4]lock(&amp;d-&gt;lock) from
aoecmd_cfg_rsp() will lead to deadlock.

So the simplest solution is breaking lock dependency
[2](&amp;d-&gt;lock) -&gt; [3](&amp;bdev-&gt;bd_size_lock) by moving set_capacity()
outside.</Note>
    </Notes>
    <CVE>CVE-2024-26775</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sis: Error out if pixclock equals zero

The userspace program could pass any values to the driver through
ioctl() interface. If the driver doesn't check the value of pixclock,
it may cause divide-by-zero error.

In sisfb_check_var(), var-&gt;pixclock is used as a divisor to caculate
drate before it is checked against zero. Fix this by checking it
at the beginning.

This is similar to CVE-2022-3061 in i740fb which was fixed by
commit 15cf0b8.</Note>
    </Notes>
    <CVE>CVE-2024-26777</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: savage: Error out if pixclock equals zero

The userspace program could pass any values to the driver through
ioctl() interface. If the driver doesn't check the value of pixclock,
it may cause divide-by-zero error.

Although pixclock is checked in savagefb_decode_var(), but it is not
checked properly in savagefb_probe(). Fix this by checking whether
pixclock is zero in the function savagefb_check_var() before
info-&gt;var.pixclock is used as the divisor.

This is similar to CVE-2022-3061 in i740fb which was fixed by
commit 15cf0b8.</Note>
    </Notes>
    <CVE>CVE-2024-26778</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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

fast-xmit must only be enabled after the sta has been uploaded to the driver,
otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls
to the driver, leading to potential crashes because of uninitialized drv_priv
data.
Add a missing sta-&gt;uploaded check and re-check fast xmit after inserting a sta.</Note>
    </Notes>
    <CVE>CVE-2024-26779</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dev-replace: properly validate device names

There's a syzbot report that device name buffers passed to device
replace are not properly checked for string termination which could lead
to a read out of bounds in getname_kernel().

Add a helper that validates both source and target device name buffers.
For devid as the source initialize the buffer to empty string in case
something tries to read it later.

This was originally analyzed and fixed in a different way by Edward Adam
Davis (see links).</Note>
    </Notes>
    <CVE>CVE-2024-26791</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use-after-free and null-ptr-deref in gtp_newlink()

The gtp_link_ops operations structure for the subsystem must be
registered after registering the gtp_net_ops pernet operations structure.

Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:

[ 1010.702740] gtp: GTP module unloaded
[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI
[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
[ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1
[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014
[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp]
[ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00
[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203
[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000
[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282
[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000
[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80
[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400
[ 1010.715953] FS:  00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000
[ 1010.715958] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0
[ 1010.715968] PKRU: 55555554
[ 1010.715972] Call Trace:
[ 1010.715985]  ? __die_body.cold+0x1a/0x1f
[ 1010.715995]  ? die_addr+0x43/0x70
[ 1010.716002]  ? exc_general_protection+0x199/0x2f0
[ 1010.716016]  ? asm_exc_general_protection+0x1e/0x30
[ 1010.716026]  ? gtp_newlink+0x4d7/0x9c0 [gtp]
[ 1010.716034]  ? gtp_net_exit+0x150/0x150 [gtp]
[ 1010.716042]  __rtnl_newlink+0x1063/0x1700
[ 1010.716051]  ? rtnl_setlink+0x3c0/0x3c0
[ 1010.716063]  ? is_bpf_text_address+0xc0/0x1f0
[ 1010.716070]  ? kernel_text_address.part.0+0xbb/0xd0
[ 1010.716076]  ? __kernel_text_address+0x56/0xa0
[ 1010.716084]  ? unwind_get_return_address+0x5a/0xa0
[ 1010.716091]  ? create_prof_cpu_mask+0x30/0x30
[ 1010.716098]  ? arch_stack_walk+0x9e/0xf0
[ 1010.716106]  ? stack_trace_save+0x91/0xd0
[ 1010.716113]  ? stack_trace_consume_entry+0x170/0x170
[ 1010.716121]  ? __lock_acquire+0x15c5/0x5380
[ 1010.716139]  ? mark_held_locks+0x9e/0xe0
[ 1010.716148]  ? kmem_cache_alloc_trace+0x35f/0x3c0
[ 1010.716155]  ? __rtnl_newlink+0x1700/0x1700
[ 1010.716160]  rtnl_newlink+0x69/0xa0
[ 1010.716166]  rtnetlink_rcv_msg+0x43b/0xc50
[ 1010.716172]  ? rtnl_fdb_dump+0x9f0/0x9f0
[ 1010.716179]  ? lock_acquire+0x1fe/0x560
[ 1010.716188]  ? netlink_deliver_tap+0x12f/0xd50
[ 1010.716196]  netlink_rcv_skb+0x14d/0x440
[ 1010.716202]  ? rtnl_fdb_dump+0x9f0/0x9f0
[ 1010.716208]  ? netlink_ack+0xab0/0xab0
[ 1010.716213]  ? netlink_deliver_tap+0x202/0xd50
[ 1010.716220]  ? netlink_deliver_tap+0x218/0xd50
[ 1010.716226]  ? __virt_addr_valid+0x30b/0x590
[ 1010.716233]  netlink_unicast+0x54b/0x800
[ 1010.716240]  ? netlink_attachskb+0x870/0x870
[ 1010.716248]  ? __check_object_size+0x2de/0x3b0
[ 1010.716254]  netlink_sendmsg+0x938/0xe40
[ 1010.716261]  ? netlink_unicast+0x800/0x800
[ 1010.716269]  ? __import_iovec+0x292/0x510
[ 1010.716276]  ? netlink_unicast+0x800/0x800
[ 1010.716284]  __sock_sendmsg+0x159/0x190
[ 1010.716290]  ____sys_sendmsg+0x712/0x880
[ 1010.716297]  ? sock_write_iter+0x3d0/0x3d0
[ 1010.716304]  ? __ia32_sys_recvmmsg+0x270/0x270
[ 1010.716309]  ? lock_acquire+0x1fe/0x560
[ 1010.716315]  ? drain_array_locked+0x90/0x90
[ 1010.716324]  ___sys_sendmsg+0xf8/0x170
[ 1010.716331]  ? sendmsg_copy_msghdr+0x170/0x170
[ 1010.716337]  ? lockdep_init_map
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26793</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter

syzbot reported the following uninit-value access issue [1]:

netlink_to_full_skb() creates a new `skb` and puts the `skb-&gt;data`
passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data
size is specified as `len` and passed to skb_put_data(). This `len`
is based on `skb-&gt;end` that is not data offset but buffer offset. The
`skb-&gt;end` contains data and tailroom. Since the tailroom is not
initialized when the new `skb` created, KMSAN detects uninitialized
memory area when copying the data.

This patch resolved this issue by correct the len from `skb-&gt;end` to
`skb-&gt;len`, which is the actual data offset.

BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]
BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline]
BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline]
BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186
 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+0x364/0x2520 lib/iov_iter.c:186
 copy_to_iter include/linux/uio.h:197 [inline]
 simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532
 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420
 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
 skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]
 packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482
 sock_recvmsg_nosec net/socket.c:1044 [inline]
 sock_recvmsg net/socket.c:1066 [inline]
 sock_read_iter+0x467/0x580 net/socket.c:1136
 call_read_iter include/linux/fs.h:2014 [inline]
 new_sync_read fs/read_write.c:389 [inline]
 vfs_read+0x8f6/0xe00 fs/read_write.c:470
 ksys_read+0x20f/0x4c0 fs/read_write.c:613
 __do_sys_read fs/read_write.c:623 [inline]
 __se_sys_read fs/read_write.c:621 [inline]
 __x64_sys_read+0x93/0xd0 fs/read_write.c:621
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Uninit was stored to memory at:
 skb_put_data include/linux/skbuff.h:2622 [inline]
 netlink_to_full_skb net/netlink/af_netlink.c:181 [inline]
 __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline]
 __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325
 netlink_deliver_tap net/netlink/af_netlink.c:338 [inline]
 netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline]
 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
 netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368
 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg net/socket.c:745 [inline]
 ____sys_sendmsg+0x9c2/0xd60 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/0x490 net/socket.c:2674
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Uninit was created at:
 free_pages_prepare mm/page_alloc.c:1087 [inline]
 free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347
 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533
 release_pages+0x23d3/0x2410 mm/swap.c:1042
 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316
 tlb_batch_pages
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26805</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/platform: Create persistent IRQ handlers

The vfio-platform SET_IRQS ioctl currently allows loopback triggering of
an interrupt before a signaling eventfd has been configured by the user,
which thereby allows a NULL pointer dereference.

Rather than register the IRQ relative to a valid trigger, register all
IRQs in a disabled state in the device open path.  This allows mask
operations on the IRQ to nest within the overall enable state governed
by a valid eventfd signal.  This decouples @masked, protected by the
@locked spinlock from @trigger, protected via the @igate mutex.

In doing so, it's guaranteed that changes to @trigger cannot race the
IRQ handlers because the IRQ handler is synchronously disabled before
modifying the trigger, and loopback triggering of the IRQ via ioctl is
safe due to serialization with trigger changes via igate.

For compatibility, request_irq() failures are maintained to be local to
the SET_IRQS ioctl rather than a fatal error in the open device path.
This allows, for example, a userspace driver with polling mode support
to continue to work regardless of moving the request_irq() call site.
This necessarily blocks all SET_IRQS access to the failed index.</Note>
    </Notes>
    <CVE>CVE-2024-26813</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86, relocs: Ignore relocations in .notes section

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

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

amdkfd: use calloc instead of kzalloc to avoid integer overflow

This uses calloc instead of doing the multiplication which might
overflow.</Note>
    </Notes>
    <CVE>CVE-2024-26817</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 underflow in parse_server_interfaces()

In this loop, we step through the buffer and after each item we check
if the size_left is greater than the minimum size we need.  However,
the problem is that "bytes_left" is type ssize_t while sizeof() is type
size_t.  That means that because of type promotion, the comparison is
done as an unsigned and if we have negative bytes left the loop
continues instead of ending.</Note>
    </Notes>
    <CVE>CVE-2024-26828</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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:

IB/hfi1: Fix a memleak in init_credit_return

When dma_alloc_coherent fails to allocate dd-&gt;cr_base[i].va,
init_credit_return should deallocate dd-&gt;cr_base and
dd-&gt;cr_base[i] that allocated before. Or those resources
would be never freed and a memleak is triggered.</Note>
    </Notes>
    <CVE>CVE-2024-26839</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cachefiles: fix memory leak in cachefiles_add_cache()

The following memory leak was reported after unbinding /dev/cachefiles:

==================================================================
unreferenced object 0xffff9b674176e3c0 (size 192):
  comm "cachefilesd2", pid 680, jiffies 4294881224
  hex dump (first 32 bytes):
    01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc ea38a44b):
    [&lt;ffffffff8eb8a1a5&gt;] kmem_cache_alloc+0x2d5/0x370
    [&lt;ffffffff8e917f86&gt;] prepare_creds+0x26/0x2e0
    [&lt;ffffffffc002eeef&gt;] cachefiles_determine_cache_security+0x1f/0x120
    [&lt;ffffffffc00243ec&gt;] cachefiles_add_cache+0x13c/0x3a0
    [&lt;ffffffffc0025216&gt;] cachefiles_daemon_write+0x146/0x1c0
    [&lt;ffffffff8ebc4a3b&gt;] vfs_write+0xcb/0x520
    [&lt;ffffffff8ebc5069&gt;] ksys_write+0x69/0xf0
    [&lt;ffffffff8f6d4662&gt;] do_syscall_64+0x72/0x140
    [&lt;ffffffff8f8000aa&gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76
==================================================================

Put the reference count of cache_cred in cachefiles_daemon_unbind() to
fix the problem. And also put cache_cred in cachefiles_add_cache() error
branch to avoid memory leaks.</Note>
    </Notes>
    <CVE>CVE-2024-26840</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: target: core: Add TMF to tmr_list handling

An abort that is responded to by iSCSI itself is added to tmr_list but does
not go to target core. A LUN_RESET that goes through tmr_list takes a
refcounter on the abort and waits for completion. However, the abort will
be never complete because it was not started in target core.

 Unable to locate ITT: 0x05000000 on CID: 0
 Unable to locate RefTaskTag: 0x05000000 on CID: 0.
 wait_for_tasks: Stopping tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop
 wait for tasks: tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop
...
 INFO: task kworker/0:2:49 blocked for more than 491 seconds.
 task:kworker/0:2     state:D stack:    0 pid:   49 ppid:     2 flags:0x00000800
 Workqueue: events target_tmr_work [target_core_mod]
Call Trace:
 __switch_to+0x2c4/0x470
 _schedule+0x314/0x1730
 schedule+0x64/0x130
 schedule_timeout+0x168/0x430
 wait_for_completion+0x140/0x270
 target_put_cmd_and_wait+0x64/0xb0 [target_core_mod]
 core_tmr_lun_reset+0x30/0xa0 [target_core_mod]
 target_tmr_work+0xc8/0x1b0 [target_core_mod]
 process_one_work+0x2d4/0x5d0
 worker_thread+0x78/0x6c0

To fix this, only add abort to tmr_list if it will be handled by target
core.</Note>
    </Notes>
    <CVE>CVE-2024-26845</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-fc: do not wait in vain when unloading module

The module exit path has race between deleting all controllers and
freeing 'left over IDs'. To prevent double free a synchronization
between nvme_delete_ctrl and ida_destroy has been added by the initial
commit.

There is some logic around trying to prevent from hanging forever in
wait_for_completion, though it does not handling all cases. E.g.
blktests is able to reproduce the situation where the module unload
hangs forever.

If we completely rely on the cleanup code executed from the
nvme_delete_ctrl path, all IDs will be freed eventually. This makes
calling ida_destroy unnecessary. We only have to ensure that all
nvme_delete_ctrl code has been executed before we leave
nvme_fc_exit_module. This is done by flushing the nvme_delete_wq
workqueue.

While at it, remove the unused nvme_fc_wq workqueue too.</Note>
    </Notes>
    <CVE>CVE-2024-26846</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()

The function ice_bridge_setlink() may encounter a NULL pointer dereference
if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently
in nla_for_each_nested(). To address this issue, add a check to ensure that
br_spec is not NULL before proceeding with the nested attribute iteration.</Note>
    </Notes>
    <CVE>CVE-2024-26855</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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

syzbot triggered a bug in geneve_rx() [1]

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

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

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

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

Uninit was created at:
  slab_post_alloc_hook mm/slub.c:3819 [inline]
  slab_alloc_node mm/slub.c:3860 [inline]
  kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
  __alloc_skb+0x352/0x790 net/core/skbuff.c:651
  alloc_skb include/linux/skbuff.h:1296 [inline]
  alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394
  sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783
  packet_alloc_skb net/packet/af_packet.c:2930 [inline]
  packet_snd net/packet/af_packet.c:3024 [inline]
  packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg net/socket.c:745 [inline]
  __sys_sendto+0x735/0xa10 net/socket.c:2191
  __do_sys_sendto net/socket.c:2203 [inline]
  __se_sys_sendto net/socket.c:2199 [inline]
  __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b</Note>
    </Notes>
    <CVE>CVE-2024-26857</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/bnx2x: Prevent access to a freed page in page_pool

Fix race condition leading to system crash during EEH error handling

During EEH error recovery, the bnx2x driver's transmit timeout logic
could cause a race condition when handling reset tasks. The
bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),
which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()
SGEs are freed using bnx2x_free_rx_sge_range(). However, this could
overlap with the EEH driver's attempt to reset the device using
bnx2x_io_slot_reset(), which also tries to free SGEs. This race
condition can result in system crashes due to accessing freed memory
locations in bnx2x_free_rx_sge()

799  static inline void bnx2x_free_rx_sge(struct bnx2x *bp,
800				struct bnx2x_fastpath *fp, u16 index)
801  {
802	struct sw_rx_page *sw_buf = &amp;fp-&gt;rx_page_ring[index];
803     struct page *page = sw_buf-&gt;page;
....
where sw_buf was set to NULL after the call to dma_unmap_page()
by the preceding thread.

    EEH: Beginning: 'slot_reset'
    PCI 0011:01:00.0#10000: EEH: Invoking bnx2x-&gt;slot_reset()
    bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing...
    bnx2x 0011:01:00.0: enabling device (0140 -&gt; 0142)
    bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --&gt; driver unload
    Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
    BUG: Kernel NULL pointer dereference on read at 0x00000000
    Faulting instruction address: 0xc0080000025065fc
    Oops: Kernel access of bad area, sig: 11 [#1]
    .....
    Call Trace:
    [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)
    [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0
    [c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550
    [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60
    [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170
    [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0
    [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64

To solve this issue, we need to verify page pool allocations before
freeing.</Note>
    </Notes>
    <CVE>CVE-2024-26859</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hsr: Fix uninit-value access in hsr_get_node()

KMSAN reported the following uninit-value access issue [1]:

=====================================================
BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
 fill_frame_info net/hsr/hsr_forward.c:577 [inline]
 hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615
 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223
 __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+0x247/0xa10 net/core/dev.c:3564
 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
 dev_queue_xmit include/linux/netdevice.h:3134 [inline]
 packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
 packet_snd net/packet/af_packet.c:3087 [inline]
 packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg net/socket.c:745 [inline]
 __sys_sendto+0x735/0xa10 net/socket.c:2191
 __do_sys_sendto net/socket.c:2203 [inline]
 __se_sys_sendto net/socket.c:2199 [inline]
 __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Uninit was created at:
 slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
 slab_alloc_node mm/slub.c:3478 [inline]
 kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523
 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
 __alloc_skb+0x318/0x740 net/core/skbuff.c:651
 alloc_skb include/linux/skbuff.h:1286 [inline]
 alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787
 packet_alloc_skb net/packet/af_packet.c:2936 [inline]
 packet_snd net/packet/af_packet.c:3030 [inline]
 packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg net/socket.c:745 [inline]
 __sys_sendto+0x735/0xa10 net/socket.c:2191
 __do_sys_sendto net/socket.c:2203 [inline]
 __se_sys_sendto net/socket.c:2199 [inline]
 __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b

CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
=====================================================

If the packet type ID field in the Ethernet header is either ETH_P_PRP or
ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr()
reads an invalid value as a sequence number. This causes the above issue.

This patch fixes the issue by returning NULL if the Ethernet header is not
followed by an HSR tag.</Note>
    </Notes>
    <CVE>CVE-2024-26863</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip

It's possible that mtk_crtc-&gt;event is NULL in
mtk_drm_crtc_finish_page_flip().

pending_needs_vblank value is set by mtk_crtc-&gt;event, but in
mtk_drm_crtc_atomic_flush(), it's is not guarded by the same
lock in mtk_drm_finish_page_flip(), thus a race condition happens.

Consider the following case:

CPU1                              CPU2
step 1:
mtk_drm_crtc_atomic_begin()
mtk_crtc-&gt;event is not null,
                                  step 1:
                                  mtk_drm_crtc_atomic_flush:
                                  mtk_drm_crtc_update_config(
                                      !!mtk_crtc-&gt;event)
step 2:
mtk_crtc_ddp_irq -&gt;
mtk_drm_finish_page_flip:
lock
mtk_crtc-&gt;event set to null,
pending_needs_vblank set to false
unlock
                                  pending_needs_vblank set to true,

                                  step 2:
                                  mtk_crtc_ddp_irq -&gt;
                                  mtk_drm_finish_page_flip called again,
                                  pending_needs_vblank is still true
                                  //null pointer

Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more
efficient to just check if mtk_crtc-&gt;event is null before use.</Note>
    </Notes>
    <CVE>CVE-2024-26874</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/bridge: adv7511: fix crash on irq during probe

Moved IRQ registration down to end of adv7511_probe().

If an IRQ already is pending during adv7511_probe
(before adv7511_cec_init) then cec_received_msg_ts
could crash using uninitialized data:

    Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5
    Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP
    Call trace:
     cec_received_msg_ts+0x48/0x990 [cec]
     adv7511_cec_irq_process+0x1cc/0x308 [adv7511]
     adv7511_irq_process+0xd8/0x120 [adv7511]
     adv7511_irq_handler+0x1c/0x30 [adv7511]
     irq_thread_fn+0x30/0xa0
     irq_thread+0x14c/0x238
     kthread+0x190/0x1a8</Note>
    </Notes>
    <CVE>CVE-2024-26876</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

quota: Fix potential NULL pointer dereference

Below race may cause NULL pointer dereference

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

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

So let's fix it by using a temporary pointer to avoid this issue.</Note>
    </Notes>
    <CVE>CVE-2024-26878</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: call the resume method on internal suspend

There is this reported crash when experimenting with the lvm2 testsuite.
The list corruption is caused by the fact that the postsuspend and resume
methods were not paired correctly; there were two consecutive calls to the
origin_postsuspend function. The second call attempts to remove the
"hash_list" entry from a list, while it was already removed by the first
call.

Fix __dm_internal_resume so that it calls the preresume and resume
methods of the table's targets.

If a preresume method of some target fails, we are in a tricky situation.
We can't return an error because dm_internal_resume isn't supposed to
return errors. We can't return success, because then the "resume" and
"postsuspend" methods would not be paired correctly. So, we set the
DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace
tools, but it won't cause a kernel crash.

------------[ cut here ]------------
kernel BUG at lib/list_debug.c:56!
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0
&lt;snip&gt;
RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282
RAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff
RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058
R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001
R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0
FS:  00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000
CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0
Call Trace:
 &lt;TASK&gt;
 ? die+0x2d/0x80
 ? do_trap+0xeb/0xf0
 ? __list_del_entry_valid_or_report+0x77/0xc0
 ? do_error_trap+0x60/0x80
 ? __list_del_entry_valid_or_report+0x77/0xc0
 ? exc_invalid_op+0x49/0x60
 ? __list_del_entry_valid_or_report+0x77/0xc0
 ? asm_exc_invalid_op+0x16/0x20
 ? table_deps+0x1b0/0x1b0 [dm_mod]
 ? __list_del_entry_valid_or_report+0x77/0xc0
 origin_postsuspend+0x1a/0x50 [dm_snapshot]
 dm_table_postsuspend_targets+0x34/0x50 [dm_mod]
 dm_suspend+0xd8/0xf0 [dm_mod]
 dev_suspend+0x1f2/0x2f0 [dm_mod]
 ? table_deps+0x1b0/0x1b0 [dm_mod]
 ctl_ioctl+0x300/0x5f0 [dm_mod]
 dm_compat_ctl_ioctl+0x7/0x10 [dm_mod]
 __x64_compat_sys_ioctl+0x104/0x170
 do_syscall_64+0x184/0x1b0
 entry_SYSCALL_64_after_hwframe+0x46/0x4e
RIP: 0033:0xf7e6aead
&lt;snip&gt;
---[ end trace 0000000000000000 ]---</Note>
    </Notes>
    <CVE>CVE-2024-26880</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix stackmap overflow check on 32-bit arches

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

The commit in the fixes tag actually attempted to fix this, but the fix
did not account for the UB, so the fix only works on CPUs where an
overflow does result in a neat truncation to zero, which is not
guaranteed. Checking the value before rounding does not have this
problem.</Note>
    </Notes>
    <CVE>CVE-2024-26883</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix hashtab overflow check on 32-bit arches

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

After unregistering the CPU idle device, the memory associated with
it is not freed, leading to a memory leak:

unreferenced object 0xffff896282f6c000 (size 1024):
  comm "swapper/0", pid 1, jiffies 4294893170
  hex dump (first 32 bytes):
    00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 8836a742):
    [&lt;ffffffff993495ed&gt;] kmalloc_trace+0x29d/0x340
    [&lt;ffffffff9972f3b3&gt;] acpi_processor_power_init+0xf3/0x1c0
    [&lt;ffffffff9972d263&gt;] __acpi_processor_start+0xd3/0xf0
    [&lt;ffffffff9972d2bc&gt;] acpi_processor_start+0x2c/0x50
    [&lt;ffffffff99805872&gt;] really_probe+0xe2/0x480
    [&lt;ffffffff99805c98&gt;] __driver_probe_device+0x78/0x160
    [&lt;ffffffff99805daf&gt;] driver_probe_device+0x1f/0x90
    [&lt;ffffffff9980601e&gt;] __driver_attach+0xce/0x1c0
    [&lt;ffffffff99803170&gt;] bus_for_each_dev+0x70/0xc0
    [&lt;ffffffff99804822&gt;] bus_add_driver+0x112/0x210
    [&lt;ffffffff99807245&gt;] driver_register+0x55/0x100
    [&lt;ffffffff9aee4acb&gt;] acpi_processor_driver_init+0x3b/0xc0
    [&lt;ffffffff990012d1&gt;] do_one_initcall+0x41/0x300
    [&lt;ffffffff9ae7c4b0&gt;] kernel_init_freeable+0x320/0x470
    [&lt;ffffffff99b231f6&gt;] kernel_init+0x16/0x1b0
    [&lt;ffffffff99042e6d&gt;] ret_from_fork+0x2d/0x50

Fix this by freeing the CPU idle device after unregistering it.</Note>
    </Notes>
    <CVE>CVE-2024-26894</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix kmemleak of rdev-&gt;serial

If kobject_add() is fail in bind_rdev_to_array(), 'rdev-&gt;serial' will be
alloc not be freed, and kmemleak occurs.

unreferenced object 0xffff88815a350000 (size 49152):
  comm "mdadm", pid 789, jiffies 4294716910
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc f773277a):
    [&lt;0000000058b0a453&gt;] kmemleak_alloc+0x61/0xe0
    [&lt;00000000366adf14&gt;] __kmalloc_large_node+0x15e/0x270
    [&lt;000000002e82961b&gt;] __kmalloc_node.cold+0x11/0x7f
    [&lt;00000000f206d60a&gt;] kvmalloc_node+0x74/0x150
    [&lt;0000000034bf3363&gt;] rdev_init_serial+0x67/0x170
    [&lt;0000000010e08fe9&gt;] mddev_create_serial_pool+0x62/0x220
    [&lt;00000000c3837bf0&gt;] bind_rdev_to_array+0x2af/0x630
    [&lt;0000000073c28560&gt;] md_add_new_disk+0x400/0x9f0
    [&lt;00000000770e30ff&gt;] md_ioctl+0x15bf/0x1c10
    [&lt;000000006cfab718&gt;] blkdev_ioctl+0x191/0x3f0
    [&lt;0000000085086a11&gt;] vfs_ioctl+0x22/0x60
    [&lt;0000000018b656fe&gt;] __x64_sys_ioctl+0xba/0xe0
    [&lt;00000000e54e675e&gt;] do_syscall_64+0x71/0x150
    [&lt;000000008b0ad622&gt;] entry_SYSCALL_64_after_hwframe+0x6c/0x74</Note>
    </Notes>
    <CVE>CVE-2024-26900</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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

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

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

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

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

Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to
solve the problem.</Note>
    </Notes>
    <CVE>CVE-2024-26901</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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:

RDMA/mlx5: Fix fortify source warning while accessing Eth segment

 ------------[ cut here ]------------
 memcpy: detected field-spanning write (size 56) of single field "eseg-&gt;inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2)
 WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
 Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy
  [last unloaded: mlx_compat(OE)]
 CPU: 0 PID: 293779 Comm: ssh Tainted: G           OE      6.2.0-32-generic #32~22.04.1-Ubuntu
 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
 Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da &lt;0f&gt; 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7
 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046
 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8
 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80
 FS:  00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  &lt;TASK&gt;
  ? show_regs+0x72/0x90
  ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
  ? __warn+0x8d/0x160
  ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
  ? report_bug+0x1bb/0x1d0
  ? handle_bug+0x46/0x90
  ? exc_invalid_op+0x19/0x80
  ? asm_exc_invalid_op+0x1b/0x20
  ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
  mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib]
  ipoib_send+0x2ec/0x770 [ib_ipoib]
  ipoib_start_xmit+0x5a0/0x770 [ib_ipoib]
  dev_hard_start_xmit+0x8e/0x1e0
  ? validate_xmit_skb_list+0x4d/0x80
  sch_direct_xmit+0x116/0x3a0
  __dev_xmit_skb+0x1fd/0x580
  __dev_queue_xmit+0x284/0x6b0
  ? _raw_spin_unlock_irq+0xe/0x50
  ? __flush_work.isra.0+0x20d/0x370
  ? push_pseudo_header+0x17/0x40 [ib_ipoib]
  neigh_connected_output+0xcd/0x110
  ip_finish_output2+0x179/0x480
  ? __smp_call_single_queue+0x61/0xa0
  __ip_finish_output+0xc3/0x190
  ip_finish_output+0x2e/0xf0
  ip_output+0x78/0x110
  ? __pfx_ip_finish_output+0x10/0x10
  ip_local_out+0x64/0x70
  __ip_queue_xmit+0x18a/0x460
  ip_queue_xmit+0x15/0x30
  __tcp_transmit_skb+0x914/0x9c0
  tcp_write_xmit+0x334/0x8d0
  tcp_push_one+0x3c/0x60
  tcp_sendmsg_locked+0x2e1/0xac0
  tcp_sendmsg+0x2d/0x50
  inet_sendmsg+0x43/0x90
  sock_sendmsg+0x68/0x80
  sock_write_iter+0x93/0x100
  vfs_write+0x326/0x3c0
  ksys_write+0xbd/0xf0
  ? do_syscall_64+0x69/0x90
  __x64_sys_write+0x19/0x30
  do_syscall_
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26907</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Reset IH OVERFLOW_CLEAR bit

Allows us to detect subsequent IH ring buffer overflows as well.</Note>
    </Notes>
    <CVE>CVE-2024-26915</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: inet_defrag: prevent sk release while still in use

ip_local_out() and other functions can pass skb-&gt;sk as function argument.

If the skb is a fragment and reassembly happens before such function call
returns, the sk must not be released.

This affects skb fragments reassembled via netfilter or similar
modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.

Eric Dumazet made an initial analysis of this bug.  Quoting Eric:
  Calling ip_defrag() in output path is also implying skb_orphan(),
  which is buggy because output path relies on sk not disappearing.

  A relevant old patch about the issue was :
  8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")

  [..]

  net/ipv4/ip_output.c depends on skb-&gt;sk being set, and probably to an
  inet socket, not an arbitrary one.

  If we orphan the packet in ipvlan, then downstream things like FQ
  packet scheduler will not work properly.

  We need to change ip_defrag() to only use skb_orphan() when really
  needed, ie whenever frag_list is going to be used.

Eric suggested to stash sk in fragment queue and made an initial patch.
However there is a problem with this:

If skb is refragmented again right after, ip_do_fragment() will copy
head-&gt;sk to the new fragments, and sets up destructor to sock_wfree.
IOW, we have no choice but to fix up sk_wmem accouting to reflect the
fully reassembled skb, else wmem will underflow.

This change moves the orphan down into the core, to last possible moment.
As ip_defrag_offset is aliased with sk_buff-&gt;sk member, we must move the
offset into the FRAG_CB, else skb-&gt;sk gets clobbered.

This allows to delay the orphaning long enough to learn if the skb has
to be queued or if the skb is completing the reasm queue.

In the former case, things work as before, skb is orphaned.  This is
safe because skb gets queued/stolen and won't continue past reasm engine.

In the latter case, we will steal the skb-&gt;sk reference, reattach it to
the head skb, and fix up wmem accouting when inet_frag inflates truesize.</Note>
    </Notes>
    <CVE>CVE-2024-26921</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: validate the parameters of bo mapping operations more clearly

Verify the parameters of
amdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.</Note>
    </Notes>
    <CVE>CVE-2024-26922</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 garbage collector racing against connect()

Garbage collector does not take into account the risk of embryo getting
enqueued during the garbage collection. If such embryo has a peer that
carries SCM_RIGHTS, two consecutive passes of scan_children() may see a
different set of children. Leading to an incorrectly elevated inflight
count, and then a dangling pointer within the gc_inflight_list.

sockets are AF_UNIX/SOCK_STREAM
S is an unconnected socket
L is a listening in-flight socket bound to addr, not in fdtable
V's fd will be passed via sendmsg(), gets inflight count bumped

connect(S, addr)	sendmsg(S, [V]); close(V)	__unix_gc()
----------------	-------------------------	-----------

NS = unix_create1()
skb1 = sock_wmalloc(NS)
L = unix_find_other(addr)
unix_state_lock(L)
unix_peer(S) = NS
			// V count=1 inflight=0

 			NS = unix_peer(S)
 			skb2 = sock_alloc()
			skb_queue_tail(NS, skb2[V])

			// V became in-flight
			// V count=2 inflight=1

			close(V)

			// V count=1 inflight=1
			// GC candidate condition met

						for u in gc_inflight_list:
						  if (total_refs == inflight_refs)
						    add u to gc_candidates

						// gc_candidates={L, V}

						for u in gc_candidates:
						  scan_children(u, dec_inflight)

						// embryo (skb1) was not
						// reachable from L yet, so V's
						// inflight remains unchanged
__skb_queue_tail(L, skb1)
unix_state_unlock(L)
						for u in gc_candidates:
						  if (u.inflight)
						    scan_children(u, inc_inflight_move_tail)

						// V count=1 inflight=2 (!)

If there is a GC-candidate listening socket, lock/unlock its state. This
makes GC wait until the end of any ongoing connect() to that socket. After
flipping the lock, a possibly SCM-laden embryo is already enqueued. And if
there is another embryo coming, it can not possibly carry SCM_RIGHTS. At
this point, unix_inflight() can not happen because unix_gc_lock is already
taken. Inflight graph remains unaffected.</Note>
    </Notes>
    <CVE>CVE-2024-26923</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential UAF in cifs_debug_files_proc_show()

Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF.</Note>
    </Notes>
    <CVE>CVE-2024-26928</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-26929</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Fix double free of the ha-&gt;vp_map pointer

Coverity scan reported potential risk of double free of the pointer
ha-&gt;vp_map.  ha-&gt;vp_map was freed in qla2x00_mem_alloc(), and again freed
in function qla2x00_mem_free(ha).

Assign NULL to vp_map and kfree take care of NULL.</Note>
    </Notes>
    <CVE>CVE-2024-26930</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Fix command flush on cable pull

System crash due to command failed to flush back to SCSI layer.

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
 PGD 0 P4D 0
 Oops: 0000 [#1] SMP NOPTI
 CPU: 27 PID: 793455 Comm: kworker/u130:6 Kdump: loaded Tainted: G           OE    --------- -  - 4.18.0-372.9.1.el8.x86_64 #1
 Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021
 Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc]
 RIP: 0010:__wake_up_common+0x4c/0x190
 Code: 24 10 4d 85 c9 74 0a 41 f6 01 04 0f 85 9d 00 00 00 48 8b 43 08 48 83 c3 08 4c 8d 48 e8 49 8d 41 18 48 39 c3 0f 84 f0 00 00 00 &lt;49&gt; 8b 41 18 89 54 24 08 31 ed 4c 8d 70 e8 45 8b 29 41 f6 c5 04 75
 RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086
 RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000
 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320
 RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8
 R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20
 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
 FS:  0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 PKRU: 55555554
 Call Trace:
  __wake_up_common_lock+0x7c/0xc0
  qla_nvme_ls_req+0x355/0x4c0 [qla2xxx]
 qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae1407ca000 from port 21:32:00:02:ac:07:ee:b8 loop_id 0x02 s_id 01:02:00 logout 1 keep 0 els_logo 0
 ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc]
 qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:00:02:ac:07:ee:b8 state transitioned from ONLINE to LOST - portid=010200.
  ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc]
 qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320002ac07eeb8. rport ffff8ae598122000 roles 1
 ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc]
 qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae14801e000 from port 21:32:01:02:ad:f7:ee:b8 loop_id 0x04 s_id 01:02:01 logout 1 keep 0 els_logo 0
  ? __switch_to+0x10c/0x450
 ? process_one_work+0x1a7/0x360
 qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:01:02:ad:f7:ee:b8 state transitioned from ONLINE to LOST - portid=010201.
  ? worker_thread+0x1ce/0x390
  ? create_worker+0x1a0/0x1a0
 qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320102adf7eeb8. rport ffff8ae3b2312800 roles 70
  ? kthread+0x10a/0x120
 qla2xxx [0000:12:00.1]-2112:3: qla_nvme_unregister_remote_port: unregister remoteport on ffff8ae14801e000 21320102adf7eeb8
  ? set_kthread_struct+0x40/0x40
 qla2xxx [0000:12:00.1]-2110:3: remoteport_delete of ffff8ae14801e000 21320102adf7eeb8 completed.
  ? ret_from_fork+0x1f/0x40
 qla2xxx [0000:12:00.1]-f086:3: qlt_free_session_done: waiting for sess ffff8ae14801e000 logout

The system was under memory stress where driver was not able to allocate an
SRB to carry out error recovery of cable pull.  The failure to flush causes
upper layer to start modifying scsi_cmnd.  When the system frees up some
memory, the subsequent cable pull trigger another command flush. At this
point the driver access a null pointer when attempting to DMA unmap the
SGL.

Add a check to make sure commands are flush back on session tear down to
prevent the null pointer access.</Note>
    </Notes>
    <CVE>CVE-2024-26931</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 deadlock in usb_deauthorize_interface()

Among the attribute file callback routines in
drivers/usb/core/sysfs.c, the interface_authorized_store() function is
the only one which acquires a device lock on an ancestor device: It
calls usb_deauthorize_interface(), which locks the interface's parent
USB device.

The will lead to deadlock if another process already owns that lock
and tries to remove the interface, whether through a configuration
change or because the device has been disconnected.  As part of the
removal procedure, device_del() waits for all ongoing sysfs attribute
callbacks to complete.  But usb_deauthorize_interface() can't complete
until the device lock has been released, and the lock won't be
released until the removal has finished.

The mechanism provided by sysfs to prevent this kind of deadlock is
to use the sysfs_break_active_protection() function, which tells sysfs
not to wait for the attribute callback.

Reported-and-tested by: Yue Sun &lt;samsun1006219@gmail.com&gt;
Reported by: xingwei lee &lt;xrivendell7@gmail.com&gt;</Note>
    </Notes>
    <CVE>CVE-2024-26934</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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

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

s390/zcrypt: fix reference counting on zcrypt card objects

Tests with hot-plugging crytpo cards on KVM guests with debug
kernel build revealed an use after free for the load field of
the struct zcrypt_card. The reason was an incorrect reference
handling of the zcrypt card object which could lead to a free
of the zcrypt card object while it was still in use.

This is an example of the slab message:

    kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b
    kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43
    kernel:  kmalloc_trace+0x3f2/0x470
    kernel:  zcrypt_card_alloc+0x36/0x70 [zcrypt]
    kernel:  zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]
    kernel:  ap_device_probe+0x15c/0x290
    kernel:  really_probe+0xd2/0x468
    kernel:  driver_probe_device+0x40/0xf0
    kernel:  __device_attach_driver+0xc0/0x140
    kernel:  bus_for_each_drv+0x8c/0xd0
    kernel:  __device_attach+0x114/0x198
    kernel:  bus_probe_device+0xb4/0xc8
    kernel:  device_add+0x4d2/0x6e0
    kernel:  ap_scan_adapter+0x3d0/0x7c0
    kernel:  ap_scan_bus+0x5a/0x3b0
    kernel:  ap_scan_bus_wq_callback+0x40/0x60
    kernel:  process_one_work+0x26e/0x620
    kernel:  worker_thread+0x21c/0x440
    kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43
    kernel:  kfree+0x37e/0x418
    kernel:  zcrypt_card_put+0x54/0x80 [zcrypt]
    kernel:  ap_device_remove+0x4c/0xe0
    kernel:  device_release_driver_internal+0x1c4/0x270
    kernel:  bus_remove_device+0x100/0x188
    kernel:  device_del+0x164/0x3c0
    kernel:  device_unregister+0x30/0x90
    kernel:  ap_scan_adapter+0xc8/0x7c0
    kernel:  ap_scan_bus+0x5a/0x3b0
    kernel:  ap_scan_bus_wq_callback+0x40/0x60
    kernel:  process_one_work+0x26e/0x620
    kernel:  worker_thread+0x21c/0x440
    kernel:  kthread+0x150/0x168
    kernel:  __ret_from_fork+0x3c/0x58
    kernel:  ret_from_fork+0xa/0x30
    kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)
    kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88
    kernel: Redzone  00000000885a74b0: bb bb bb bb bb bb bb bb                          ........
    kernel: Object   00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
    kernel: Object   00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
    kernel: Object   00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
    kernel: Object   00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
    kernel: Object   00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
    kernel: Object   00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5  kkkkkkkkkkhKkkk.
    kernel: Redzone  00000000885a7518: bb bb bb bb bb bb bb bb                          ........
    kernel: Padding  00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a              ZZZZZZZZZZZZ
    kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2
    kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)
    kernel: Call Trace:
    kernel:  [&lt;00000000ca5ab5b8&gt;] dump_stack_lvl+0x90/0x120
    kernel:  [&lt;00000000c99d78bc&gt;] check_bytes_and_report+0x114/0x140
    kernel:  [&lt;00000000c99d53cc&gt;] check_object+0x334/0x3f8
    kernel:  [&lt;00000000c99d820c&gt;] alloc_debug_processing+0xc4/0x1f8
    kernel:  [&lt;00000000c99d852e&gt;] get_partial_node.part.0+0x1ee/0x3e0
    kernel:  [&lt;00000000c99d94ec&gt;] ___slab_alloc+0xaf4/0x13c8
    kernel:  [&lt;00000000c99d9e38&gt;] __slab_alloc.constprop.0+0x78/0xb8
    kernel:  [&lt;00000000c99dc8dc&gt;] __kmalloc+0x434/0x590
    kernel:  [&lt;00000000c9b4c0ce&gt;] ext4_htree_store_dirent+0x4e/0x1c0
    kernel:  [&lt;00000000c9b908a2&gt;] htree_dirblock_to_tree+0x17a/0x3f0
    kernel: 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26957</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfs: fix UAF in direct writes

In production we have been hitting the following warning consistently

------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0
Workqueue: nfsiod nfs_direct_write_schedule_work [nfs]
RIP: 0010:refcount_warn_saturate+0x9c/0xe0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? __warn+0x9f/0x130
 ? refcount_warn_saturate+0x9c/0xe0
 ? report_bug+0xcc/0x150
 ? handle_bug+0x3d/0x70
 ? exc_invalid_op+0x16/0x40
 ? asm_exc_invalid_op+0x16/0x20
 ? refcount_warn_saturate+0x9c/0xe0
 nfs_direct_write_schedule_work+0x237/0x250 [nfs]
 process_one_work+0x12f/0x4a0
 worker_thread+0x14e/0x3b0
 ? ZSTD_getCParams_internal+0x220/0x220
 kthread+0xdc/0x120
 ? __btf_name_valid+0xa0/0xa0
 ret_from_fork+0x1f/0x30

This is because we're completing the nfs_direct_request twice in a row.

The source of this is when we have our commit requests to submit, we
process them and send them off, and then in the completion path for the
commit requests we have

if (nfs_commit_end(cinfo.mds))
	nfs_direct_write_complete(dreq);

However since we're submitting asynchronous requests we sometimes have
one that completes before we submit the next one, so we end up calling
complete on the nfs_direct_request twice.

The only other place we use nfs_generic_commit_list() is in
__nfs_commit_inode, which wraps this call in a

nfs_commit_begin();
nfs_commit_end();

Which is a common pattern for this style of completion handling, one
that is also repeated in the direct code with get_dreq()/put_dreq()
calls around where we process events as well as in the completion paths.

Fix this by using the same pattern for the commit requests.

Before with my 200 node rocksdb stress running this warning would pop
every 10ish minutes.  With my patch the stress test has been running for
several hours without popping.</Note>
    </Notes>
    <CVE>CVE-2024-26958</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fat: fix uninitialized field in nostale filehandles

When fat_encode_fh_nostale() encodes file handle without a parent it
stores only first 10 bytes of the file handle. However the length of the
file handle must be a multiple of 4 so the file handle is actually 12
bytes long and the last two bytes remain uninitialized. This is not
great at we potentially leak uninitialized information with the handle
to userspace. Properly initialize the full handle length.</Note>
    </Notes>
    <CVE>CVE-2024-26973</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nouveau: fix instmem race condition around ptr stores

Running a lot of VK CTS in parallel against nouveau, once every
few hours you might see something like this crash.

BUG: kernel NULL pointer dereference, address: 0000000000000008
PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27
Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021
RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]
Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee &lt;48&gt; 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1
RSP: 0000:ffffac20c5857838 EFLAGS: 00010202
RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001
RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180
RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10
R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c
R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c
FS:  00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:

...

 ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]
 ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau]
 nvkm_vmm_iter+0x351/0xa20 [nouveau]
 ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]
 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
 ? __lock_acquire+0x3ed/0x2170
 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
 nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau]
 ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]
 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
 nvkm_vmm_map_locked+0x224/0x3a0 [nouveau]

Adding any sort of useful debug usually makes it go away, so I hand
wrote the function in a line, and debugged the asm.

Every so often pt-&gt;memory-&gt;ptrs is NULL. This ptrs ptr is set in
the nv50_instobj_acquire called from nvkm_kmap.

If Thread A and Thread B both get to nv50_instobj_acquire around
the same time, and Thread A hits the refcount_set line, and in
lockstep thread B succeeds at refcount_inc_not_zero, there is a
chance the ptrs value won't have been stored since refcount_set
is unordered. Force a memory barrier here, I picked smp_mb, since
we want it on all CPUs and it's write followed by a read.

v2: use paired smp_rmb/smp_wmb.</Note>
    </Notes>
    <CVE>CVE-2024-26984</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fs: sysfs: Fix reference leak in sysfs_break_active_protection()

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

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

usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error

When ncm function is working and then stop usb0 interface for link down,
eth_stop() is called. At this piont, accidentally if usb transport error
should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled.

After that, ncm_disable() is called to disable for ncm unbind
but gether_disconnect() is never called since 'in_ep' is not enabled.

As the result, ncm object is released in ncm unbind
but 'dev-&gt;port_usb' associated to 'ncm-&gt;port' is not NULL.

And when ncm bind again to recover netdev, ncm object is reallocated
but usb0 interface is already associated to previous released ncm object.

Therefore, once usb0 interface is up and eth_start_xmit() is called,
released ncm object is dereferrenced and it might cause use-after-free memory.

[function unlink via configfs]
  usb0: eth_stop dev-&gt;port_usb=ffffff9b179c3200
  --&gt; error happens in usb_ep_enable().
  NCM: ncm_disable: ncm=ffffff9b179c3200
  --&gt; no gether_disconnect() since ncm-&gt;port.in_ep-&gt;enabled is false.
  NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200
  NCM: ncm_free: ncm free ncm=ffffff9b179c3200   &lt;-- released ncm

[function link via configfs]
  NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000
  NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000
  NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0
  usb0: eth_open dev-&gt;port_usb=ffffff9b179c3200  &lt;-- previous released ncm
  usb0: eth_start dev-&gt;port_usb=ffffff9b179c3200 &lt;--
  eth_start_xmit()
  --&gt; dev-&gt;wrap()
  Unable to handle kernel paging request at virtual address dead00000000014f

This patch addresses the issue by checking if 'ncm-&gt;netdev' is not NULL at
ncm_disable() to call gether_disconnect() to deassociate 'dev-&gt;port_usb'.
It's more reasonable to check 'ncm-&gt;netdev' to call gether_connect/disconnect
rather than check 'ncm-&gt;port.in_ep-&gt;enabled' since it might not be enabled
but the gether connection might be established.</Note>
    </Notes>
    <CVE>CVE-2024-26996</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: nv04: Fix out of bounds access

When Output Resource (dcb-&gt;or) value is assigned in
fabricate_dcb_output(), there may be out of bounds access to
dac_users array in case dcb-&gt;or is zero because ffs(dcb-&gt;or) is
used as index there.
The 'or' argument of fabricate_dcb_output() must be interpreted as a
number of bit to set, not value.

Utilize macros from 'enum nouveau_or' in calls instead of hardcoding.

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

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

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

net_ratelimit mechanism can be used to limit the dumping rate.

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

net/mlx5e: Prevent deadlock while disabling aRFS

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

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

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

Kernel log:

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

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

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

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

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

other info that might help us debug this:

 Possible unsafe locking scenario:

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

 *** DEADLOCK ***

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

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

nfp: flower: handle acti_netdevs allocation failure

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

This patch adds a check to judge whether allocation failure occurs.
If it happens, the delayed work will be rescheduled and try again.</Note>
    </Notes>
    <CVE>CVE-2024-27046</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

s390/dasd: fix double module refcount decrement

Once the discipline is associated with the device, deleting the device
takes care of decrementing the module's refcount.  Doing it manually on
this error path causes refcount to artificially decrease on each error
while it should just stay the same.</Note>
    </Notes>
    <CVE>CVE-2024-27054</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: usb-storage: Prevent divide-by-0 error in isd200_ata_command

The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values
in the ATA ID information to calculate cylinder and head values when
creating a CDB for READ or WRITE commands.  The calculation involves
division and modulus operations, which will cause a crash if either of
these values is 0.  While this never happens with a genuine device, it
could happen with a flawed or subversive emulation, as reported by the
syzbot fuzzer.

Protect against this possibility by refusing to bind to the device if
either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID
information is 0.  This requires isd200_Initialization() to return a
negative error code when initialization fails; currently it always
returns 0 (even when there is an error).</Note>
    </Notes>
    <CVE>CVE-2024-27059</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nouveau: lock the client object tree.

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

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

Remove locks calls in usbtv_video_free() because
are useless and may led to a deadlock as reported here:
https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000
Also remove usbtv_stop() call since it will be called when
unregistering the device.

Before 'c838530d230b' this issue would only be noticed if you
disconnect while streaming and now it is noticeable even when
disconnecting while not streaming.


[hverkuil: fix minor spelling mistake in log message]</Note>
    </Notes>
    <CVE>CVE-2024-27072</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ttpci: fix two memleaks in budget_av_attach

When saa7146_register_device and saa7146_vv_init fails, budget_av_attach
should free the resources it allocates, like the error-handling of
ttpci_budget_init does. Besides, there are two fixme comment refers to
such deallocations.</Note>
    </Notes>
    <CVE>CVE-2024-27073</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: go7007: fix a memleak in go7007_load_encoder

In go7007_load_encoder, bounce(i.e. go-&gt;boot_fw), is allocated without
a deallocation thereafter. After the following call chain:

saa7134_go7007_init
  |-&gt; go7007_boot_encoder
        |-&gt; go7007_load_encoder
  |-&gt; kfree(go)

go is freed and thus bounce is leaked.</Note>
    </Notes>
    <CVE>CVE-2024-27074</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: avoid stack overflow warnings with clang

A previous patch worked around a KASAN issue in stv0367, now a similar
problem showed up with clang:

drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than]
 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)

Rework the stv0367_writereg() function to be simpler and mark both
register access functions as noinline_for_stack so the temporary
i2c_msg structures do not get duplicated on the stack when KASAN_STACK
is enabled.</Note>
    </Notes>
    <CVE>CVE-2024-27075</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: v4l2-tpg: fix some memleaks in tpg_alloc

In tpg_alloc, resources should be deallocated in each and every
error-handling paths, since they are allocated in for statements.
Otherwise there would be memleaks because tpg_free is called only when
tpg_alloc return 0.</Note>
    </Notes>
    <CVE>CVE-2024-27078</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 some memleaks in gssx_dec_option_array

The creds and oa-&gt;data need to be freed in the error-handling paths after
their allocation. So this patch add these deallocations in the
corresponding paths.</Note>
    </Notes>
    <CVE>CVE-2024-27388</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: gtp: Fix Use-After-Free in gtp_dellink

Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal
of gtp_dellink, is not part of the RCU read critical section, it
is possible that the RCU grace period will pass during the traversal and
the key will be free.

To prevent this, it should be changed to hlist_for_each_entry_safe.</Note>
    </Notes>
    <CVE>CVE-2024-27396</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use-after-free bugs caused by sco_sock_timeout

When the sco connection is established and then, the sco socket
is releasing, timeout_work will be scheduled to judge whether
the sco disconnection is timeout. The sock will be deallocated
later, but it is dereferenced again in sco_sock_timeout. As a
result, the use-after-free bugs will happen. The root cause is
shown below:

    Cleanup Thread               |      Worker Thread
sco_sock_release                 |
  sco_sock_close                 |
    __sco_sock_close             |
      sco_sock_set_timer         |
        schedule_delayed_work    |
  sco_sock_kill                  |    (wait a time)
    sock_put(sk) //FREE          |  sco_sock_timeout
                                 |    sock_hold(sk) //USE

The KASAN report triggered by POC is shown below:

[   95.890016] ==================================================================
[   95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0
[   95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7
...
[   95.890755] Workqueue: events sco_sock_timeout
[   95.890755] Call Trace:
[   95.890755]  &lt;TASK&gt;
[   95.890755]  dump_stack_lvl+0x45/0x110
[   95.890755]  print_address_description+0x78/0x390
[   95.890755]  print_report+0x11b/0x250
[   95.890755]  ? __virt_addr_valid+0xbe/0xf0
[   95.890755]  ? sco_sock_timeout+0x5e/0x1c0
[   95.890755]  kasan_report+0x139/0x170
[   95.890755]  ? update_load_avg+0xe5/0x9f0
[   95.890755]  ? sco_sock_timeout+0x5e/0x1c0
[   95.890755]  kasan_check_range+0x2c3/0x2e0
[   95.890755]  sco_sock_timeout+0x5e/0x1c0
[   95.890755]  process_one_work+0x561/0xc50
[   95.890755]  worker_thread+0xab2/0x13c0
[   95.890755]  ? pr_cont_work+0x490/0x490
[   95.890755]  kthread+0x279/0x300
[   95.890755]  ? pr_cont_work+0x490/0x490
[   95.890755]  ? kthread_blkcg+0xa0/0xa0
[   95.890755]  ret_from_fork+0x34/0x60
[   95.890755]  ? kthread_blkcg+0xa0/0xa0
[   95.890755]  ret_from_fork_asm+0x11/0x20
[   95.890755]  &lt;/TASK&gt;
[   95.890755]
[   95.890755] Allocated by task 506:
[   95.890755]  kasan_save_track+0x3f/0x70
[   95.890755]  __kasan_kmalloc+0x86/0x90
[   95.890755]  __kmalloc+0x17f/0x360
[   95.890755]  sk_prot_alloc+0xe1/0x1a0
[   95.890755]  sk_alloc+0x31/0x4e0
[   95.890755]  bt_sock_alloc+0x2b/0x2a0
[   95.890755]  sco_sock_create+0xad/0x320
[   95.890755]  bt_sock_create+0x145/0x320
[   95.890755]  __sock_create+0x2e1/0x650
[   95.890755]  __sys_socket+0xd0/0x280
[   95.890755]  __x64_sys_socket+0x75/0x80
[   95.890755]  do_syscall_64+0xc4/0x1b0
[   95.890755]  entry_SYSCALL_64_after_hwframe+0x67/0x6f
[   95.890755]
[   95.890755] Freed by task 506:
[   95.890755]  kasan_save_track+0x3f/0x70
[   95.890755]  kasan_save_free_info+0x40/0x50
[   95.890755]  poison_slab_object+0x118/0x180
[   95.890755]  __kasan_slab_free+0x12/0x30
[   95.890755]  kfree+0xb2/0x240
[   95.890755]  __sk_destruct+0x317/0x410
[   95.890755]  sco_sock_release+0x232/0x280
[   95.890755]  sock_close+0xb2/0x210
[   95.890755]  __fput+0x37f/0x770
[   95.890755]  task_work_run+0x1ae/0x210
[   95.890755]  get_signal+0xe17/0xf70
[   95.890755]  arch_do_signal_or_restart+0x3f/0x520
[   95.890755]  syscall_exit_to_user_mode+0x55/0x120
[   95.890755]  do_syscall_64+0xd1/0x1b0
[   95.890755]  entry_SYSCALL_64_after_hwframe+0x67/0x6f
[   95.890755]
[   95.890755] The buggy address belongs to the object at ffff88800c388000
[   95.890755]  which belongs to the cache kmalloc-1k of size 1024
[   95.890755] The buggy address is located 128 bytes inside of
[   95.890755]  freed 1024-byte region [ffff88800c388000, ffff88800c388400)
[   95.890755]
[   95.890755] The buggy address belongs to the physical page:
[   95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388
[   95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
[   95.890755] ano
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-27398</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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: l2cap: fix null-ptr-deref in l2cap_chan_timeout

There is a race condition between l2cap_chan_timeout() and
l2cap_chan_del(). When we use l2cap_chan_del() to delete the
channel, the chan-&gt;conn will be set to null. But the conn could
be dereferenced again in the mutex_lock() of l2cap_chan_timeout().
As a result the null pointer dereference bug will happen. The
KASAN report triggered by POC is shown below:

[  472.074580] ==================================================================
[  472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0
[  472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7
[  472.075308]
[  472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36
[  472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4
[  472.075308] Workqueue: events l2cap_chan_timeout
[  472.075308] Call Trace:
[  472.075308]  &lt;TASK&gt;
[  472.075308]  dump_stack_lvl+0x137/0x1a0
[  472.075308]  print_report+0x101/0x250
[  472.075308]  ? __virt_addr_valid+0x77/0x160
[  472.075308]  ? mutex_lock+0x68/0xc0
[  472.075308]  kasan_report+0x139/0x170
[  472.075308]  ? mutex_lock+0x68/0xc0
[  472.075308]  kasan_check_range+0x2c3/0x2e0
[  472.075308]  mutex_lock+0x68/0xc0
[  472.075308]  l2cap_chan_timeout+0x181/0x300
[  472.075308]  process_one_work+0x5d2/0xe00
[  472.075308]  worker_thread+0xe1d/0x1660
[  472.075308]  ? pr_cont_work+0x5e0/0x5e0
[  472.075308]  kthread+0x2b7/0x350
[  472.075308]  ? pr_cont_work+0x5e0/0x5e0
[  472.075308]  ? kthread_blkcg+0xd0/0xd0
[  472.075308]  ret_from_fork+0x4d/0x80
[  472.075308]  ? kthread_blkcg+0xd0/0xd0
[  472.075308]  ret_from_fork_asm+0x11/0x20
[  472.075308]  &lt;/TASK&gt;
[  472.075308] ==================================================================
[  472.094860] Disabling lock debugging due to kernel taint
[  472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158
[  472.096136] #PF: supervisor write access in kernel mode
[  472.096136] #PF: error_code(0x0002) - not-present page
[  472.096136] PGD 0 P4D 0
[  472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI
[  472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G    B              6.9.0-rc5-00356-g78c0094a146b #36
[  472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4
[  472.096136] Workqueue: events l2cap_chan_timeout
[  472.096136] RIP: 0010:mutex_lock+0x88/0xc0
[  472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88
[  472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246
[  472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865
[  472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78
[  472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f
[  472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000
[  472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00
[  472.096136] FS:  0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000
[  472.096136] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0
[  472.096136] Call Trace:
[  472.096136]  &lt;TASK&gt;
[  472.096136]  ? __die_body+0x8d/0xe0
[  472.096136]  ? page_fault_oops+0x6b8/0x9a0
[  472.096136]  ? kernelmode_fixup_or_oops+0x20c/0x2a0
[  472.096136]  ? do_user_addr_fault+0x1027/0x1340
[  472.096136]  ? _printk+0x7a/0xa0
[  472.096136]  ? mutex_lock+0x68/0xc0
[  472.096136]  ? add_taint+0x42/0xd0
[  472.096136]  ? exc_page_fault+0x6a/0x1b0
[  472.096136]  ? asm_exc_page_fault+0x26/0x30
[  472.096136]  ? mutex_lock+0x75/0xc0
[  472.096136]  ? mutex_lock+0x88/0xc0
[  472.096136]  ? mutex_lock+0x75/0xc0
[  472.096136]  l2cap_chan_timeo
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-27399</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

firewire: nosy: ensure user_length is taken into account when fetching packet contents

Ensure that packet_buffer_get respects the user_length provided. If
the length of the head packet exceeds the user_length, packet_buffer_get
will now return 0 to signify to the user that no data were read
and a larger buffer size is required. Helps prevent user space overflows.</Note>
    </Notes>
    <CVE>CVE-2024-27401</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: nl80211: reject iftype change with mesh ID change

It's currently possible to change the mesh ID when the
interface isn't yet in mesh mode, at the same time as
changing it into mesh mode. This leads to an overwrite
of data in the wdev-&gt;u union for the interface type it
currently has, causing cfg80211_change_iface() to do
wrong things when switching.

We could probably allow setting an interface to mesh
while setting the mesh ID at the same time by doing a
different order of operations here, but realistically
there's no userspace that's going to do this, so just
disallow changes in iftype when setting mesh ID.</Note>
    </Notes>
    <CVE>CVE-2024-27410</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netrom: Fix data-races around sysctl_net_busy_read

We need to protect the reader reading the sysctl value because the
value can be changed concurrently.</Note>
    </Notes>
    <CVE>CVE-2024-27419</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: Stop parsing channels bits when all channels are found.

If a usb audio device sets more bits than the amount of channels
it could write outside of the map array.</Note>
    </Notes>
    <CVE>CVE-2024-27436</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 iconv() function in the GNU C Library versions 2.39 and older may overflow the output buffer passed to it by up to 4 bytes when converting strings to the ISO-2022-CN-EXT character set, which may be used to crash an application or overwrite a neighbouring variable.
</Note>
    </Notes>
    <CVE>CVE-2024-2961</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-2.22-114.34.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-i18ndata-2.22-114.34.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-locale-2.22-114.34.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:nscd-2.22-114.34.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">less through 653 allows OS command execution via a newline character in the name of a file, because quoting is mishandled in filename.c. Exploitation typically requires use with attacker-controlled file names, such as the files extracted from an untrusted archive. Exploitation also requires the LESSOPEN environment variable, but this is set by default in many common cases.</Note>
    </Notes>
    <CVE>CVE-2024-32487</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:less-458-7.15.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">nscd: Stack-based buffer overflow in netgroup cache

If the Name Service Cache Daemon's (nscd) fixed size cache is exhausted
by client requests then a subsequent client request for netgroup data
may result in a stack-based buffer overflow.  This flaw was introduced
in glibc 2.15 when the cache was added to nscd.

This vulnerability is only present in the nscd binary.
</Note>
    </Notes>
    <CVE>CVE-2024-33599</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-2.22-114.34.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-i18ndata-2.22-114.34.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-locale-2.22-114.34.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:nscd-2.22-114.34.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">nscd: Null pointer crashes after notfound response

If the Name Service Cache Daemon's (nscd) cache fails to add a not-found
netgroup response to the cache, the client request can result in a null
pointer dereference.  This flaw was introduced in glibc 2.15 when the
cache was added to nscd.

This vulnerability is only present in the nscd binary.

</Note>
    </Notes>
    <CVE>CVE-2024-33600</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-2.22-114.34.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-i18ndata-2.22-114.34.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-locale-2.22-114.34.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:nscd-2.22-114.34.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">nscd: netgroup cache may terminate daemon on memory allocation failure

The Name Service Cache Daemon's (nscd) netgroup cache uses xmalloc or
xrealloc and these functions may terminate the process due to a memory
allocation failure resulting in a denial of service to the clients.  The
flaw was introduced in glibc 2.15 when the cache was added to nscd.

This vulnerability is only present in the nscd binary.

</Note>
    </Notes>
    <CVE>CVE-2024-33601</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-2.22-114.34.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-i18ndata-2.22-114.34.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-locale-2.22-114.34.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:nscd-2.22-114.34.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">nscd: netgroup cache assumes NSS callback uses in-buffer strings

The Name Service Cache Daemon's (nscd) netgroup cache can corrupt memory
when the NSS callback does not store all strings in the provided buffer.
The flaw was introduced in glibc 2.15 when the cache was added to nscd.

This vulnerability is only present in the nscd binary.

</Note>
    </Notes>
    <CVE>CVE-2024-33602</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-2.22-114.34.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-i18ndata-2.22-114.34.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glibc-locale-2.22-114.34.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:nscd-2.22-114.34.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 GNOME GLib before 2.78.5, and 2.79.x and 2.80.x before 2.80.1. When a GDBus-based client subscribes to signals from a trusted system service such as NetworkManager on a shared computer, other users of the same computer can send spoofed D-Bus signals that the GDBus-based client will wrongly interpret as having been sent by the trusted system service. This could lead to the GDBus-based client behaving incorrectly, with an application-dependent impact.</Note>
    </Notes>
    <CVE>CVE-2024-34397</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:glib2-tools-2.48.2-12.37.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libgio-2_0-0-2.48.2-12.37.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libglib-2_0-0-2.48.2-12.37.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libgmodule-2_0-0-2.48.2-12.37.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libgobject-2_0-0-2.48.2-12.37.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 xmllint (from libxml2) before 2.11.8 and 2.12.x before 2.12.7. Formatting error messages with xmllint --htmlout can result in a buffer over-read in xmlHTMLPrintFileContext in xmllint.c.</Note>
    </Notes>
    <CVE>CVE-2024-34459</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libxml2-2-2.9.4-46.75.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">Requests is a HTTP library. Prior to 2.32.0, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. This vulnerability is fixed in 2.32.0.</Note>
    </Notes>
    <CVE>CVE-2024-35195</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:python-requests-2.24.0-8.17.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.8 and earlier, when starting the cupsd server with a Listen configuration item pointing to a symbolic link, the cupsd process can be caused to perform an arbitrary chmod of the provided argument, providing world-writable access to the target. Given that cupsd is often running as root, this can result in the change of permission of any user or system files to be world writable. Given the aforementioned Ubuntu AppArmor context, on such systems this vulnerability is limited to those files modifiable by the cupsd process. In that specific case it was found to be possible to turn the configuration of the Listen argument into full control over the cupsd.conf and cups-files.conf configuration files. By later setting the User and Group arguments in cups-files.conf, and printing with a printer configured by PPD with a `FoomaticRIPCommandLine` argument, arbitrary user and group (not root) command execution could be achieved, which can further be used on Ubuntu systems to achieve full root command execution. Commit ff1f8a623e090dee8a8aadf12a6a4b25efac143d contains a patch for the issue.
</Note>
    </Notes>
    <CVE>CVE-2024-35235</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:cups-libs-1.7.5-20.49.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fpga: region: add owner module and take its refcount

The current implementation of the fpga region assumes that the low-level
module registers a driver for the parent device and uses its owner pointer
to take the module's refcount. This approach is problematic since it can
lead to a null pointer dereference while attempting to get the region
during programming if the parent device does not have a driver.

To address this problem, add a module owner pointer to the fpga_region
struct and use it to take the module's refcount. Modify the functions for
registering a region to take an additional owner module parameter and
rename them to avoid conflicts. Use the old function names for helper
macros that automatically set the module that registers the region as the
owner. This ensures compatibility with existing low-level control modules
and reduces the chances of registering a region without setting the owner.

Also, update the documentation to keep it consistent with the new interface
for registering an fpga region.</Note>
    </Notes>
    <CVE>CVE-2024-35247</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes

When moving a station out of a VLAN and deleting the VLAN afterwards, the
fast_rx entry still holds a pointer to the VLAN's netdev, which can cause
use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx
after the VLAN change.</Note>
    </Notes>
    <CVE>CVE-2024-35789</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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:

KVM: SVM: Flush pages under kvm-&gt;lock to fix UAF in svm_register_enc_region()

Do the cache flush of converted pages in svm_register_enc_region() before
dropping kvm-&gt;lock to fix use-after-free issues where region and/or its
array of pages could be freed by a different task, e.g. if userspace has
__unregister_enc_region_locked() already queued up for the region.

Note, the "obvious" alternative of using local variables doesn't fully
resolve the bug, as region-&gt;pages is also dynamically allocated.  I.e. the
region structure itself would be fine, but region-&gt;pages could be freed.

Flushing multiple pages under kvm-&gt;lock is unfortunate, but the entire
flow is a rare slow path, and the manual flush is only needed on CPUs that
lack coherency for encrypted memory.</Note>
    </Notes>
    <CVE>CVE-2024-35791</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 snapshot: fix lockup in dm_exception_table_exit

There was reported lockup when we exit a snapshot with many exceptions.
Fix this by adding "cond_resched" to the loop that frees the exceptions.</Note>
    </Notes>
    <CVE>CVE-2024-35805</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 corruption during on-line resize

We observed a corruption during on-line resize of a file system that is
larger than 16 TiB with 4k block size. With having more then 2^32 blocks
resize_inode is turned off by default by mke2fs. The issue can be
reproduced on a smaller file system for convenience by explicitly
turning off resize_inode. An on-line resize across an 8 GiB boundary (the
size of a meta block group in this setup) then leads to a corruption:

  dev=/dev/&lt;some_dev&gt; # should be &gt;= 16 GiB
  mkdir -p /corruption
  /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15))
  mount -t ext4 $dev /corruption

  dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15))
  sha1sum /corruption/test
  # 79d2658b39dcfd77274e435b0934028adafaab11  /corruption/test

  /sbin/resize2fs $dev $((2*2**21))
  # drop page cache to force reload the block from disk
  echo 1 &gt; /proc/sys/vm/drop_caches

  sha1sum /corruption/test
  # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3  /corruption/test

2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per
block group and 2^6 are the number of block groups that make a meta
block group.

The last checksum might be different depending on how the file is laid
out across the physical blocks. The actual corruption occurs at physical
block 63*2^15 = 2064384 which would be the location of the backup of the
meta block group's block descriptor. During the on-line resize the file
system will be converted to meta_bg starting at s_first_meta_bg which is
2 in the example - meaning all block groups after 16 GiB. However, in
ext4_flex_group_add we might add block groups that are not part of the
first meta block group yet. In the reproducer we achieved this by
substracting the size of a whole block group from the point where the
meta block group would start. This must be considered when updating the
backup block group descriptors to follow the non-meta_bg layout. The fix
is to add a test whether the group to add is already part of the meta
block group or not.</Note>
    </Notes>
    <CVE>CVE-2024-35807</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/PM: Drain runtime-idle callbacks before driver removal

A race condition between the .runtime_idle() callback and the .remove()
callback in the rtsx_pcr PCI driver leads to a kernel crash due to an
unhandled page fault [1].

The problem is that rtsx_pci_runtime_idle() is not expected to be running
after pm_runtime_get_sync() has been called, but the latter doesn't really
guarantee that.  It only guarantees that the suspend and resume callbacks
will not be running when it returns.

However, if a .runtime_idle() callback is already running when
pm_runtime_get_sync() is called, the latter will notice that the runtime PM
status of the device is RPM_ACTIVE and it will return right away without
waiting for the former to complete.  In fact, it cannot wait for
.runtime_idle() to complete because it may be called from that callback (it
arguably does not make much sense to do that, but it is not strictly
prohibited).

Thus in general, whoever is providing a .runtime_idle() callback needs
to protect it from running in parallel with whatever code runs after
pm_runtime_get_sync().  [Note that .runtime_idle() will not start after
pm_runtime_get_sync() has returned, but it may continue running then if it
has started earlier.]

One way to address that race condition is to call pm_runtime_barrier()
after pm_runtime_get_sync() (not before it, because a nonzero value of the
runtime PM usage counter is necessary to prevent runtime PM callbacks from
being invoked) to wait for the .runtime_idle() callback to complete should
it be running at that point.  A suitable place for doing that is in
pci_device_remove() which calls pm_runtime_get_sync() before removing the
driver, so it may as well call pm_runtime_barrier() subsequently, which
will prevent the race in question from occurring, not just in the rtsx_pcr
driver, but in any PCI drivers providing .runtime_idle() callbacks.</Note>
    </Notes>
    <CVE>CVE-2024-35809</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: udc: remove warning when queue disabled ep

It is possible trigger below warning message from mass storage function,

WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104
pc : usb_ep_queue+0x7c/0x104
lr : fsg_main_thread+0x494/0x1b3c

Root cause is mass storage function try to queue request from main thread,
but other thread may already disable ep when function disable.

As there is no function failure in the driver, in order to avoid effort
to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().</Note>
    </Notes>
    <CVE>CVE-2024-35822</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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: libertas: fix some memleaks in lbs_allocate_cmd_buffer()

In the for statement of lbs_allocate_cmd_buffer(), if the allocation of
cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to
be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().</Note>
    </Notes>
    <CVE>CVE-2024-35828</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: tc358743: register v4l2 async device only after successful setup

Ensure the device has been setup correctly before registering the v4l2
async device, thus allowing userspace to access.</Note>
    </Notes>
    <CVE>CVE-2024-35830</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 a double-free in arfs_create_groups

When `in` allocated by kvzalloc fails, arfs_create_groups will free
ft-&gt;g and return an error. However, arfs_create_table, the only caller of
arfs_create_groups, will hold this error and call to
mlx5e_destroy_flow_table, in which the ft-&gt;g will be freed again.</Note>
    </Notes>
    <CVE>CVE-2024-35835</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 information leak in btrfs_ioctl_logical_to_ino()

Syzbot reported the following information leak for in
btrfs_ioctl_logical_to_ino():

  BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
  BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40
   instrument_copy_to_user include/linux/instrumented.h:114 [inline]
   _copy_to_user+0xbc/0x110 lib/usercopy.c:40
   copy_to_user include/linux/uaccess.h:191 [inline]
   btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499
   btrfs_ioctl+0x714/0x1260
   vfs_ioctl fs/ioctl.c:51 [inline]
   __do_sys_ioctl fs/ioctl.c:904 [inline]
   __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
   __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
   x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
   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:
   __kmalloc_large_node+0x231/0x370 mm/slub.c:3921
   __do_kmalloc_node mm/slub.c:3954 [inline]
   __kmalloc_node+0xb07/0x1060 mm/slub.c:3973
   kmalloc_node include/linux/slab.h:648 [inline]
   kvmalloc_node+0xc0/0x2d0 mm/util.c:634
   kvmalloc include/linux/slab.h:766 [inline]
   init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779
   btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480
   btrfs_ioctl+0x714/0x1260
   vfs_ioctl fs/ioctl.c:51 [inline]
   __do_sys_ioctl fs/ioctl.c:904 [inline]
   __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
   __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
   x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
   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

  Bytes 40-65535 of 65536 are uninitialized
  Memory access of size 65536 starts at ffff888045a40000

This happens, because we're copying a 'struct btrfs_data_container' back
to user-space. This btrfs_data_container is allocated in
'init_data_container()' via kvmalloc(), which does not zero-fill the
memory.

Fix this by using kvzalloc() which zeroes out the memory on allocation.</Note>
    </Notes>
    <CVE>CVE-2024-35849</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential UAF in smb2_is_network_name_deleted()

Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF.</Note>
    </Notes>
    <CVE>CVE-2024-35862</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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:

smb: client: fix potential UAF in is_valid_oplock_break()

Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF.</Note>
    </Notes>
    <CVE>CVE-2024-35863</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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:

smb: client: fix potential UAF in smb2_is_valid_lease_break()

Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF.</Note>
    </Notes>
    <CVE>CVE-2024-35864</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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:

smb: client: fix potential UAF in smb2_is_valid_oplock_break()

Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF.</Note>
    </Notes>
    <CVE>CVE-2024-35865</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential UAF in cifs_stats_proc_show()

Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF.</Note>
    </Notes>
    <CVE>CVE-2024-35867</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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:

smb: client: fix potential UAF in cifs_stats_proc_write()

Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF.</Note>
    </Notes>
    <CVE>CVE-2024-35868</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 smb2_reconnect_server()

The UAF bug is due to smb2_reconnect_server() accessing a session that
is already being teared down by another thread that is executing
__cifs_put_smb_ses().  This can happen when (a) the client has
connection to the server but no session or (b) another thread ends up
setting @ses-&gt;ses_status again to something different than
SES_EXITING.

To fix this, we need to make sure to unconditionally set
@ses-&gt;ses_status to SES_EXITING and prevent any other threads from
setting a new status while we're still tearing it down.

The following can be reproduced by adding some delay to right after
the ipc is freed in __cifs_put_smb_ses() - which will give
smb2_reconnect_server() worker a chance to run and then accessing
@ses-&gt;ipc:

kinit ...
mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10
[disconnect srv]
ls /mnt/1 &amp;&gt;/dev/null
sleep 30
kdestroy
[reconnect srv]
sleep 10
umount /mnt/1
...
CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
CIFS: VFS: \\srv Send error in SessSetup = -126
CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
CIFS: VFS: \\srv Send error in SessSetup = -126
general protection fault, probably for non-canonical address
0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI
CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39
04/01/2014
Workqueue: cifsiod smb2_reconnect_server [cifs]
RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0
Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad
de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 &lt;48&gt; 8b 01 48 39 f8 75
7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8
RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83
RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b
RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800
RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000
R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000
FS: 0000000000000000(0000) GS:ffff888157c00000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? die_addr+0x36/0x90
 ? exc_general_protection+0x1c1/0x3f0
 ? asm_exc_general_protection+0x26/0x30
 ? __list_del_entry_valid_or_report+0x33/0xf0
 __cifs_put_smb_ses+0x1ae/0x500 [cifs]
 smb2_reconnect_server+0x4ed/0x710 [cifs]
 process_one_work+0x205/0x6b0
 worker_thread+0x191/0x360
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe2/0x110
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x34/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-35870</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86/mm/pat: fix VM_PAT handling in COW mappings

PAT handling won't do the right thing in COW mappings: the first PTE (or,
in fact, all PTEs) can be replaced during write faults to point at anon
folios.  Reliably recovering the correct PFN and cachemode using
follow_phys() from PTEs will not work in COW mappings.

Using follow_phys(), we might just get the address+protection of the anon
folio (which is very wrong), or fail on swap/nonswap entries, failing
follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and
track_pfn_copy(), not properly calling free_pfn_range().

In free_pfn_range(), we either wouldn't call memtype_free() or would call
it with the wrong range, possibly leaking memory.

To fix that, let's update follow_phys() to refuse returning anon folios,
and fallback to using the stored PFN inside vma-&gt;vm_pgoff for COW mappings
if we run into that.

We will now properly handle untrack_pfn() with COW mappings, where we
don't need the cachemode.  We'll have to fail fork()-&gt;track_pfn_copy() if
the first page was replaced by an anon folio, though: we'd have to store
the cachemode in the VMA to make this work, likely growing the VMA size.

For now, lets keep it simple and let track_pfn_copy() just fail in that
case: it would have failed in the past with swap/nonswap entries already,
and it would have done the wrong thing with anon folios.

Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():

&lt;--- C reproducer ---&gt;
 #include &lt;stdio.h&gt;
 #include &lt;sys/mman.h&gt;
 #include &lt;unistd.h&gt;
 #include &lt;liburing.h&gt;

 int main(void)
 {
         struct io_uring_params p = {};
         int ring_fd;
         size_t size;
         char *map;

         ring_fd = io_uring_setup(1, &amp;p);
         if (ring_fd &lt; 0) {
                 perror("io_uring_setup");
                 return 1;
         }
         size = p.sq_off.array + p.sq_entries * sizeof(unsigned);

         /* Map the submission queue ring MAP_PRIVATE */
         map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
                    ring_fd, IORING_OFF_SQ_RING);
         if (map == MAP_FAILED) {
                 perror("mmap");
                 return 1;
         }

         /* We have at least one page. Let's COW it. */
         *map = 0;
         pause();
         return 0;
 }
&lt;--- C reproducer ---&gt;

On a system with 16 GiB RAM and swap configured:
 # ./iouring &amp;
 # memhog 16G
 # killall iouring
[  301.552930] ------------[ cut here ]------------
[  301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100
[  301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g
[  301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1
[  301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4
[  301.559569] RIP: 0010:untrack_pfn+0xf4/0x100
[  301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000
[  301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282
[  301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047
[  301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200
[  301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000
[  301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000
[  301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000
[  301.564186] FS:  0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000
[  301.564773] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0
[  301.565725] PKRU: 55555554
[  301.565944] Call Trace:
[  301.566148]  &lt;TASK&gt;
[  301.566325]  ? untrack_pfn+0xf4/0x100
[  301.566618]  ? __warn+0x81/0x130
[  301.566876]  ? untrack_pfn+0xf4/0x100
[  3
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-35877</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: module: prevent NULL pointer dereference in vsnprintf()

In of_modalias(), we can get passed the str and len parameters which would
cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr
when the length is also 0. Also, we need to filter out the negative values
of the len parameter as these will result in a really huge buffer since
snprintf() takes size_t parameter while ours is ssize_t...

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

ipv6: Fix infinite recursion in fib6_dump_done().

syzkaller reported infinite recursive calls of fib6_dump_done() during
netlink socket destruction.  [1]

From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then
the response was generated.  The following recvmmsg() resumed the dump
for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due
to the fault injection.  [0]

  12:01:34 executing program 3:
  r0 = socket$nl_route(0x10, 0x3, 0x0)
  sendmsg$nl_route(r0, ... snip ...)
  recvmmsg(r0, ... snip ...) (fail_nth: 8)

Here, fib6_dump_done() was set to nlk_sk(sk)-&gt;cb.done, and the next call
of inet6_dump_fib() set it to nlk_sk(sk)-&gt;cb.args[3].  syzkaller stopped
receiving the response halfway through, and finally netlink_sock_destruct()
called nlk_sk(sk)-&gt;cb.done().

fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)-&gt;cb.done() if it
is still not NULL.  fib6_dump_end() rewrites nlk_sk(sk)-&gt;cb.done() by
nlk_sk(sk)-&gt;cb.args[3], but it has the same function, not NULL, calling
itself recursively and hitting the stack guard page.

To avoid the issue, let's set the destructor after kzalloc().

[0]:
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl (lib/dump_stack.c:117)
 should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)
 should_failslab (mm/slub.c:3733)
 kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)
 inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)
 rtnl_dump_all (net/core/rtnetlink.c:4029)
 netlink_dump (net/netlink/af_netlink.c:2269)
 netlink_recvmsg (net/netlink/af_netlink.c:1988)
 ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)
 ___sys_recvmsg (net/socket.c:2846)
 do_recvmmsg (net/socket.c:2943)
 __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)

[1]:
BUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)
stack guard page: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Workqueue: events netlink_sock_destruct_work
RIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)
Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd &lt;53&gt; 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff
RSP: 0018:ffffc9000d980000 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3
RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358
RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000
R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68
FS:  0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:
 &lt;#DF&gt;
 &lt;/#DF&gt;
 &lt;TASK&gt;
 fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
 fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
 ...
 fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
 fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
 netlink_sock_destruct (net/netlink/af_netlink.c:401)
 __sk_destruct (net/core/sock.c:2177 (discriminator 2))
 sk_destruct (net/core/sock.c:2224)
 __sk_free (net/core/sock.c:2235)
 sk_free (net/core/sock.c:2246)
 process_one_work (kernel/workqueue.c:3259)
 worker_thread (kernel/workqueue.c:3329 kernel/workqueue.
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-35886</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: validate user input for expected length

I got multiple syzbot reports showing old bugs exposed
by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc
in cgroup/{s,g}etsockopt")

setsockopt() @optlen argument should be taken into account
before copying data.

 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 do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]
 BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627
Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238

CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
  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
  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
  __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105
  copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
  copy_from_sockptr include/linux/sockptr.h:55 [inline]
  do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]
  do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627
  nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101
  do_sock_setsockopt+0x3af/0x720 net/socket.c:2311
  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334
  __do_sys_setsockopt net/socket.c:2343 [inline]
  __se_sys_setsockopt net/socket.c:2340 [inline]
  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
 do_syscall_64+0xfb/0x240
 entry_SYSCALL_64_after_hwframe+0x72/0x7a
RIP: 0033:0x7fd22067dde9
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:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9
RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000
R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8
 &lt;/TASK&gt;

Allocated by task 7238:
  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:370 [inline]
  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
  kasan_kmalloc include/linux/kasan.h:211 [inline]
  __do_kmalloc_node mm/slub.c:4069 [inline]
  __kmalloc_noprof+0x200/0x410 mm/slub.c:4082
  kmalloc_noprof include/linux/slab.h:664 [inline]
  __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869
  do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293
  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334
  __do_sys_setsockopt net/socket.c:2343 [inline]
  __se_sys_setsockopt net/socket.c:2340 [inline]
  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
 do_syscall_64+0xfb/0x240
 entry_SYSCALL_64_after_hwframe+0x72/0x7a

The buggy address belongs to the object at ffff88802cd73da0
 which belongs to the cache kmalloc-8 of size 8
The buggy address is located 0 bytes inside of
 allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)

The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73
flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)
page_type: 0xffffefff(slab)
raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122
raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-35896</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fbmon: prevent division by zero in fb_videomode_from_videomode()

The expression htotal * vtotal can have a zero value on
overflow. It is necessary to prevent division by zero like in
fb_var_to_videomode().

Found by Linux Verification Center (linuxtesting.org) with Svace.</Note>
    </Notes>
    <CVE>CVE-2024-35922</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: prevent division by zero in blk_rq_stat_sum()

The expression dst-&gt;nr_samples + src-&gt;nr_samples may
have zero value on overflow. It is necessary to add
a check to avoid division by zero.

Found by Linux Verification Center (linuxtesting.org) with Svace.</Note>
    </Notes>
    <CVE>CVE-2024-35925</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()

The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an
unsuccessful status.  In such cases, the elsiocb is not issued, the
completion is not called, and thus the elsiocb resource is leaked.

Check return value after calling lpfc_sli4_resume_rpi() and conditionally
release the elsiocb resource.</Note>
    </Notes>
    <CVE>CVE-2024-35930</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: don't check if plane-&gt;state-&gt;fb == state-&gt;fb

Currently, when using non-blocking commits, we can see the following
kernel warning:

[  110.908514] ------------[ cut here ]------------
[  110.908529] refcount_t: underflow; use-after-free.
[  110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0
[  110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6
[  110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G         C         6.1.66-v8+ #32
[  110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
[  110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  110.909132] pc : refcount_dec_not_one+0xb8/0xc0
[  110.909152] lr : refcount_dec_not_one+0xb4/0xc0
[  110.909170] sp : ffffffc00913b9c0
[  110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60
[  110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480
[  110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78
[  110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000
[  110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004
[  110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003
[  110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00
[  110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572
[  110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000
[  110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001
[  110.909434] Call trace:
[  110.909441]  refcount_dec_not_one+0xb8/0xc0
[  110.909461]  vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]
[  110.909903]  vc4_cleanup_fb+0x44/0x50 [vc4]
[  110.910315]  drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]
[  110.910669]  vc4_atomic_commit_tail+0x390/0x9dc [vc4]
[  110.911079]  commit_tail+0xb0/0x164 [drm_kms_helper]
[  110.911397]  drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]
[  110.911716]  drm_atomic_commit+0xb0/0xdc [drm]
[  110.912569]  drm_mode_atomic_ioctl+0x348/0x4b8 [drm]
[  110.913330]  drm_ioctl_kernel+0xec/0x15c [drm]
[  110.914091]  drm_ioctl+0x24c/0x3b0 [drm]
[  110.914850]  __arm64_sys_ioctl+0x9c/0xd4
[  110.914873]  invoke_syscall+0x4c/0x114
[  110.914897]  el0_svc_common+0xd0/0x118
[  110.914917]  do_el0_svc+0x38/0xd0
[  110.914936]  el0_svc+0x30/0x8c
[  110.914958]  el0t_64_sync_handler+0x84/0xf0
[  110.914979]  el0t_64_sync+0x18c/0x190
[  110.914996] ---[ end trace 0000000000000000 ]---

This happens because, although `prepare_fb` and `cleanup_fb` are
perfectly balanced, we cannot guarantee consistency in the check
plane-&gt;state-&gt;fb == state-&gt;fb. This means that sometimes we can increase
the refcount in `prepare_fb` and don't decrease it in `cleanup_fb`. The
opposite can also be true.

In fact, the struct drm_plane .state shouldn't be accessed directly
but instead, the `drm_atomic_get_new_plane_state()` helper function should
be used. So, we could stick to this check, but using
`drm_atomic_get_new_plane_state()`. But actually, this check is not re
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-35932</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: send: handle path ref underflow in header iterate_inode_ref()

Change BUG_ON to proper error handling if building the path buffer
fails. The pointers are not printed so we don't accidentally leak kernel
addresses.</Note>
    </Notes>
    <CVE>CVE-2024-35935</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 chunk tree lookup error in btrfs_relocate_sys_chunks()

The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,
as it could be caused only by two impossible conditions:

- at first the search key is set up to look for a chunk tree item, with
  offset -1, this is an inexact search and the key-&gt;offset will contain
  the correct offset upon a successful search, a valid chunk tree item
  cannot have an offset -1

- after first successful search, the found_key corresponds to a chunk
  item, the offset is decremented by 1 before the next loop, it's
  impossible to find a chunk item there due to alignment and size
  constraints</Note>
    </Notes>
    <CVE>CVE-2024-35936</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 memcpy() run-time warning in dg_dispatch_as_host()

Syzkaller hit 'WARNING in dg_dispatch_as_host' bug.

memcpy: detected field-spanning write (size 56) of single field "&amp;dg_info-&gt;msg"
at drivers/misc/vmw_vmci/vmci_datagram.c:237 (size 24)

WARNING: CPU: 0 PID: 1555 at drivers/misc/vmw_vmci/vmci_datagram.c:237
dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237

Some code commentry, based on my understanding:

544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)-&gt;payload_size)
/// This is 24 + payload_size

memcpy(&amp;dg_info-&gt;msg, dg, dg_size);
	Destination = dg_info-&gt;msg ---&gt; this is a 24 byte
					structure(struct vmci_datagram)
	Source = dg --&gt; this is a 24 byte structure (struct vmci_datagram)
	Size = dg_size = 24 + payload_size

{payload_size = 56-24 =32} -- Syzkaller managed to set payload_size to 32.

 35 struct delayed_datagram_info {
 36         struct datagram_entry *entry;
 37         struct work_struct work;
 38         bool in_dg_host_queue;
 39         /* msg and msg_payload must be together. */
 40         struct vmci_datagram msg;
 41         u8 msg_payload[];
 42 };

So those extra bytes of payload are copied into msg_payload[], a run time
warning is seen while fuzzing with Syzkaller.

One possible way to fix the warning is to split the memcpy() into
two parts -- one -- direct assignment of msg and second taking care of payload.

Gustavo quoted:
"Under FORTIFY_SOURCE we should not copy data across multiple members
in a structure."</Note>
    </Notes>
    <CVE>CVE-2024-35944</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dyndbg: fix old BUG_ON in &gt;control parser

Fix a BUG_ON from 2009.  Even if it looks "unreachable" (I didn't
really look), lets make sure by removing it, doing pr_err and return
-EINVAL instead.</Note>
    </Notes>
    <CVE>CVE-2024-35947</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/client: Fully protect modes[] with dev-&gt;mode_config.mutex

The modes[] array contains pointers to modes on the connectors'
mode lists, which are protected by dev-&gt;mode_config.mutex.
Thus we need to extend modes[] the same protection or by the
time we use it the elements may already be pointing to
freed/reused memory.</Note>
    </Notes>
    <CVE>CVE-2024-35950</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

kprobes: Fix possible use-after-free issue on kprobe registration

When unloading a module, its state is changing MODULE_STATE_LIVE -&gt;
 MODULE_STATE_GOING -&gt; MODULE_STATE_UNFORMED. Each change will take
a time. `is_module_text_address()` and `__module_text_address()`
works with MODULE_STATE_LIVE and MODULE_STATE_GOING.
If we use `is_module_text_address()` and `__module_text_address()`
separately, there is a chance that the first one is succeeded but the
next one is failed because module-&gt;state becomes MODULE_STATE_UNFORMED
between those operations.

In `check_kprobe_address_safe()`, if the second `__module_text_address()`
is failed, that is ignored because it expected a kernel_text address.
But it may have failed simply because module-&gt;state has been changed
to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify
non-exist module text address (use-after-free).

To fix this problem, we should not use separated `is_module_text_address()`
and `__module_text_address()`, but use only `__module_text_address()`
once and do `try_module_get(module)` which is only available with
MODULE_STATE_LIVE.</Note>
    </Notes>
    <CVE>CVE-2024-35955</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 qgroup prealloc rsv leak in subvolume operations

Create subvolume, create snapshot and delete subvolume all use
btrfs_subvolume_reserve_metadata() to reserve metadata for the changes
done to the parent subvolume's fs tree, which cannot be mediated in the
normal way via start_transaction. When quota groups (squota or qgroups)
are enabled, this reserves qgroup metadata of type PREALLOC. Once the
operation is associated to a transaction, we convert PREALLOC to
PERTRANS, which gets cleared in bulk at the end of the transaction.

However, the error paths of these three operations were not implementing
this lifecycle correctly. They unconditionally converted the PREALLOC to
PERTRANS in a generic cleanup step regardless of errors or whether the
operation was fully associated to a transaction or not. This resulted in
error paths occasionally converting this rsv to PERTRANS without calling
record_root_in_trans successfully, which meant that unless that root got
recorded in the transaction by some other thread, the end of the
transaction would not free that root's PERTRANS, leaking it. Ultimately,
this resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmount
for the leaked reservation.

The fix is to ensure that every qgroup PREALLOC reservation observes the
following properties:

1. any failure before record_root_in_trans is called successfully
   results in freeing the PREALLOC reservation.
2. after record_root_in_trans, we convert to PERTRANS, and now the
   transaction owns freeing the reservation.

This patch enforces those properties on the three operations. Without
it, generic/269 with squotas enabled at mkfs time would fail in ~5-10
runs on my system. With this patch, it ran successfully 1000 times in a
row.</Note>
    </Notes>
    <CVE>CVE-2024-35956</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix incorrect descriptor free behavior

ENA has two types of TX queues:
- queues which only process TX packets arriving from the network stack
- queues which only process TX packets forwarded to it by XDP_REDIRECT
  or XDP_TX instructions

The ena_free_tx_bufs() cycles through all descriptors in a TX queue
and unmaps + frees every descriptor that hasn't been acknowledged yet
by the device (uncompleted TX transactions).
The function assumes that the processed TX queue is necessarily from
the first category listed above and ends up using napi_consume_skb()
for descriptors belonging to an XDP specific queue.

This patch solves a bug in which, in case of a VF reset, the
descriptors aren't freed correctly, leading to crashes.</Note>
    </Notes>
    <CVE>CVE-2024-35958</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Properly link new fs rules into the tree

Previously, add_rule_fg would only add newly created rules from the
handle into the tree when they had a refcount of 1. On the other hand,
create_flow_handle tries hard to find and reference already existing
identical rules instead of creating new ones.

These two behaviors can result in a situation where create_flow_handle
1) creates a new rule and references it, then
2) in a subsequent step during the same handle creation references it
   again,
resulting in a rule with a refcount of 2 that is not linked into the
tree, will have a NULL parent and root and will result in a crash when
the flow group is deleted because del_sw_hw_rule, invoked on rule
deletion, assumes node-&gt;parent is != NULL.

This happened in the wild, due to another bug related to incorrect
handling of duplicate pkt_reformat ids, which lead to the code in
create_flow_handle incorrectly referencing a just-added rule in the same
flow handle, resulting in the problem described above. Full details are
at [1].

This patch changes add_rule_fg to add new rules without parents into
the tree, properly initializing them and avoiding the crash. This makes
it more consistent with how rules are added to an FTE in
create_flow_handle.</Note>
    </Notes>
    <CVE>CVE-2024-35960</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr

Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it
still means hlist_for_each_entry_rcu can return an item that got removed
from the list. The memory itself of such item is not freed thanks to RCU
but nothing guarantees the actual content of the memory is sane.

In particular, the reference count can be zero. This can happen if
ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry
from inet6_addr_lst (hlist_del_init_rcu(&amp;ifp-&gt;addr_lst)) and drops all
references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough
timing, this can happen:

1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.

2. Then, the whole ipv6_del_addr is executed for the given entry. The
   reference count drops to zero and kfree_rcu is scheduled.

3. ipv6_get_ifaddr continues and tries to increments the reference count
   (in6_ifa_hold).

4. The rcu is unlocked and the entry is freed.

5. The freed entry is returned.

Prevent increasing of the reference count in such case. The name
in6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.

[   41.506330] refcount_t: addition on 0; use-after-free.
[   41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130
[   41.507413] Modules linked in: veth bridge stp llc
[   41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14
[   41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
[   41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130
[   41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 &lt;0f&gt; 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff
[   41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282
[   41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000
[   41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900
[   41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff
[   41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000
[   41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48
[   41.514086] FS:  00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000
[   41.514726] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0
[   41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   41.516799] Call Trace:
[   41.517037]  &lt;TASK&gt;
[   41.517249]  ? __warn+0x7b/0x120
[   41.517535]  ? refcount_warn_saturate+0xa5/0x130
[   41.517923]  ? report_bug+0x164/0x190
[   41.518240]  ? handle_bug+0x3d/0x70
[   41.518541]  ? exc_invalid_op+0x17/0x70
[   41.520972]  ? asm_exc_invalid_op+0x1a/0x20
[   41.521325]  ? refcount_warn_saturate+0xa5/0x130
[   41.521708]  ipv6_get_ifaddr+0xda/0xe0
[   41.522035]  inet6_rtm_getaddr+0x342/0x3f0
[   41.522376]  ? __pfx_inet6_rtm_getaddr+0x10/0x10
[   41.522758]  rtnetlink_rcv_msg+0x334/0x3d0
[   41.523102]  ? netlink_unicast+0x30f/0x390
[   41.523445]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10
[   41.523832]  netlink_rcv_skb+0x53/0x100
[   41.524157]  netlink_unicast+0x23b/0x390
[   41.524484]  netlink_sendmsg+0x1f2/0x440
[   41.524826]  __sys_sendto+0x1d8/0x1f0
[   41.525145]  __x64_sys_sendto+0x1f/0x30
[   41.525467]  do_syscall_64+0xa5/0x1b0
[   41.525794]  entry_SYSCALL_64_after_hwframe+0x72/0x7a
[   41.526213] RIP: 0033:0x7fbc4cfcea9a
[   41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89
[   41.527942] RSP: 002b:00007f
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-35969</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING

syzbot reported an illegal copy in xsk_setsockopt() [1]

Make sure to validate setsockopt() @optlen parameter.

[1]

 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 xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549

CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
  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
  copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
  copy_from_sockptr include/linux/sockptr.h:55 [inline]
  xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
  do_sock_setsockopt+0x3af/0x720 net/socket.c:2311
  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334
  __do_sys_setsockopt net/socket.c:2343 [inline]
  __se_sys_setsockopt net/socket.c:2340 [inline]
  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
 do_syscall_64+0xfb/0x240
 entry_SYSCALL_64_after_hwframe+0x6d/0x75
RIP: 0033:0x7fb40587de69
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:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69
RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006
RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000
R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08
 &lt;/TASK&gt;

Allocated by task 7549:
  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:370 [inline]
  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
  kasan_kmalloc include/linux/kasan.h:211 [inline]
  __do_kmalloc_node mm/slub.c:3966 [inline]
  __kmalloc+0x233/0x4a0 mm/slub.c:3979
  kmalloc include/linux/slab.h:632 [inline]
  __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869
  do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293
  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334
  __do_sys_setsockopt net/socket.c:2343 [inline]
  __se_sys_setsockopt net/socket.c:2340 [inline]
  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
 do_syscall_64+0xfb/0x240
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

The buggy address belongs to the object at ffff888028c6cde0
 which belongs to the cache kmalloc-8 of size 8
The buggy address is located 1 bytes to the right of
 allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)

The buggy address belongs to the physical page:
page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c
anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)
page_type: 0xffffffff()
raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001
raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223
  set_page_owner include/linux/page_owner.h:31 [inline]
  post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533
  prep_new_page mm/page_alloc.c:
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-35976</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

raid1: fix use-after-free for original bio in raid1_write_request()

r1_bio-&gt;bios[] is used to record new bios that will be issued to
underlying disks, however, in raid1_write_request(), r1_bio-&gt;bios[]
will set to the original bio temporarily. Meanwhile, if blocked rdev
is set, free_r1bio() will be called causing that all r1_bio-&gt;bios[]
to be freed:

raid1_write_request()
 r1_bio = alloc_r1bio(mddev, bio); -&gt; r1_bio-&gt;bios[] is NULL
 for (i = 0;  i &lt; disks; i++) -&gt; for each rdev in conf
  // first rdev is normal
  r1_bio-&gt;bios[0] = bio; -&gt; set to original bio
  // second rdev is blocked
  if (test_bit(Blocked, &amp;rdev-&gt;flags))
   break

 if (blocked_rdev)
  free_r1bio()
   put_all_bios()
    bio_put(r1_bio-&gt;bios[0]) -&gt; original bio is freed

Test scripts:

mdadm -CR /dev/md0 -l1 -n4 /dev/sd[abcd] --assume-clean
fio -filename=/dev/md0 -ioengine=libaio -rw=write -bs=4k -numjobs=1 \
    -iodepth=128 -name=test -direct=1
echo blocked &gt; /sys/block/md0/md/rd2/state

Test result:

BUG bio-264 (Not tainted): Object already free
-----------------------------------------------------------------------------

Allocated in mempool_alloc_slab+0x24/0x50 age=1 cpu=1 pid=869
 kmem_cache_alloc+0x324/0x480
 mempool_alloc_slab+0x24/0x50
 mempool_alloc+0x6e/0x220
 bio_alloc_bioset+0x1af/0x4d0
 blkdev_direct_IO+0x164/0x8a0
 blkdev_write_iter+0x309/0x440
 aio_write+0x139/0x2f0
 io_submit_one+0x5ca/0xb70
 __do_sys_io_submit+0x86/0x270
 __x64_sys_io_submit+0x22/0x30
 do_syscall_64+0xb1/0x210
 entry_SYSCALL_64_after_hwframe+0x6c/0x74
Freed in mempool_free_slab+0x1f/0x30 age=1 cpu=1 pid=869
 kmem_cache_free+0x28c/0x550
 mempool_free_slab+0x1f/0x30
 mempool_free+0x40/0x100
 bio_free+0x59/0x80
 bio_put+0xf0/0x220
 free_r1bio+0x74/0xb0
 raid1_make_request+0xadf/0x1150
 md_handle_request+0xc7/0x3b0
 md_submit_bio+0x76/0x130
 __submit_bio+0xd8/0x1d0
 submit_bio_noacct_nocheck+0x1eb/0x5c0
 submit_bio_noacct+0x169/0xd40
 submit_bio+0xee/0x1d0
 blkdev_direct_IO+0x322/0x8a0
 blkdev_write_iter+0x309/0x440
 aio_write+0x139/0x2f0

Since that bios for underlying disks are not allocated yet, fix this
problem by using mempool_free() directly to free the r1_bio.</Note>
    </Notes>
    <CVE>CVE-2024-35979</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

batman-adv: Avoid infinite loop trying to resize local TT

If the MTU of one of an attached interface becomes too small to transmit
the local translation table then it must be resized to fit inside all
fragments (when enabled) or a single packet.

But if the MTU becomes too low to transmit even the header + the VLAN
specific part then the resizing of the local TT will never succeed. This
can for example happen when the usable space is 110 bytes and 11 VLANs are
on top of batman-adv. In this case, at least 116 byte would be needed.
There will just be an endless spam of

   batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)

in the log but the function will never finish. Problem here is that the
timeout will be halved all the time and will then stagnate at 0 and
therefore never be able to reduce the table even more.

There are other scenarios possible with a similar result. The number of
BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too
high to fit inside a packet. Such a scenario can therefore happen also with
only a single VLAN + 7 non-purgable addresses - requiring at least 120
bytes.

While this should be handled proactively when:

* interface with too low MTU is added
* VLAN is added
* non-purgeable local mac is added
* MTU of an attached interface is reduced
* fragmentation setting gets disabled (which most likely requires dropping
  attached interfaces)

not all of these scenarios can be prevented because batman-adv is only
consuming events without the the possibility to prevent these actions
(non-purgable MAC address added, MTU of an attached interface is reduced).
It is therefore necessary to also make sure that the code is able to handle
also the situations when there were already incompatible system
configuration are present.</Note>
    </Notes>
    <CVE>CVE-2024-35982</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: smbus: fix NULL function pointer dereference

Baruch reported an OOPS when using the designware controller as target
only. Target-only modes break the assumption of one transfer function
always being available. Fix this by always checking the pointer in
__i2c_transfer.

[wsa: dropped the simplification in core-smbus to avoid theoretical regressions]</Note>
    </Notes>
    <CVE>CVE-2024-35984</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up

The flag I2C_HID_READ_PENDING is used to serialize I2C operations.
However, this is not necessary, because I2C core already has its own
locking for that.

More importantly, this flag can cause a lock-up: if the flag is set in
i2c_hid_xfer() and an interrupt happens, the interrupt handler
(i2c_hid_irq) will check this flag and return immediately without doing
anything, then the interrupt handler will be invoked again in an
infinite loop.

Since interrupt handler is an RT task, it takes over the CPU and the
flag-clearing task never gets scheduled, thus we have a lock-up.

Delete this unnecessary flag.</Note>
    </Notes>
    <CVE>CVE-2024-35997</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb3: fix lock ordering potential deadlock in cifs_sync_mid_result

Coverity spotted that the cifs_sync_mid_result function could deadlock

"Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquires
lock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock"

Addresses-Coverity: 1590401 ("Thread deadlock (ORDER_REVERSAL)")</Note>
    </Notes>
    <CVE>CVE-2024-35998</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/arm/malidp: fix a possible null pointer dereference

In malidp_mw_connector_reset, new memory is allocated with kzalloc, but
no check is performed. In order to prevent null pointer dereferencing,
ensure that mw_state is checked before calling
__drm_atomic_helper_connector_reset.</Note>
    </Notes>
    <CVE>CVE-2024-36014</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ppdev: Add an error check in register_device

In register_device, the return value of ida_simple_get is unchecked,
in witch ida_simple_get will use an invalid index value.

To address this issue, index should be checked after ida_simple_get. When
the index value is abnormal, a warning message should be printed, the port
should be dropped, and the value should be recorded.</Note>
    </Notes>
    <CVE>CVE-2024-36015</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 possible out-of-bounds in gsm0_receive()

Assuming the following:
- side A configures the n_gsm in basic option mode
- side B sends the header of a basic option mode frame with data length 1
- side A switches to advanced option mode
- side B sends 2 data bytes which exceeds gsm-&gt;len
  Reason: gsm-&gt;len is not used in advanced option mode.
- side A switches to basic option mode
- side B keeps sending until gsm0_receive() writes past gsm-&gt;buf
  Reason: Neither gsm-&gt;state nor gsm-&gt;len have been reset after
  reconfiguration.

Fix this by changing gsm-&gt;count to gsm-&gt;len comparison from equal to less
than. Also add upper limit checks against the constant MAX_MRU in
gsm0_receive() and gsm1_receive() to harden against memory corruption of
gsm-&gt;len and gsm-&gt;mru.

All other checks remain as we still need to limit the data according to the
user configuration and actual payload size.</Note>
    </Notes>
    <CVE>CVE-2024-36016</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation

Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a
struct ifla_vf_vlan_info so the size of such attribute needs to be at least
of sizeof(struct ifla_vf_vlan_info) which is 14 bytes.
The current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes)
which is less than sizeof(struct ifla_vf_vlan_info) so this validation
is not enough and a too small attribute might be cast to a
struct ifla_vf_vlan_info, this might result in an out of bands
read access when accessing the saved (casted) entry in ivvl.</Note>
    </Notes>
    <CVE>CVE-2024-36017</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 off by one in qla_edif_app_getstats()

The app_reply-&gt;elem[] array is allocated earlier in this function and it
has app_req.num_ports elements.  Thus this &gt; comparison needs to be &gt;= to
prevent memory corruption.</Note>
    </Notes>
    <CVE>CVE-2024-36025</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sdhci-msm: pervent access to suspended controller

Generic sdhci code registers LED device and uses host-&gt;runtime_suspended
flag to protect access to it. The sdhci-msm driver doesn't set this flag,
which causes a crash when LED is accessed while controller is runtime
suspended. Fix this by setting the flag correctly.</Note>
    </Notes>
    <CVE>CVE-2024-36029</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fpga: bridge: add owner module and take its refcount

The current implementation of the fpga bridge assumes that the low-level
module registers a driver for the parent device and uses its owner pointer
to take the module's refcount. This approach is problematic since it can
lead to a null pointer dereference while attempting to get the bridge if
the parent device does not have a driver.

To address this problem, add a module owner pointer to the fpga_bridge
struct and use it to take the module's refcount. Modify the function for
registering a bridge to take an additional owner module parameter and
rename it to avoid conflicts. Use the old function name for a helper macro
that automatically sets the module that registers the bridge as the owner.
This ensures compatibility with existing low-level control modules and
reduces the chances of registering a bridge without setting the owner.

Also, update the documentation to keep it consistent with the new interface
for registering an fpga bridge.

Other changes: opportunistically move put_device() from __fpga_bridge_get()
to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since
the bridge device is taken in these functions.</Note>
    </Notes>
    <CVE>CVE-2024-36479</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qca: add missing firmware sanity checks

Add the missing sanity checks when parsing the firmware files before
downloading them to avoid accessing and corrupting memory beyond the
vmalloced buffer.</Note>
    </Notes>
    <CVE>CVE-2024-36880</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete

FFS based applications can utilize the aio_cancel() callback to dequeue
pending USB requests submitted to the UDC.  There is a scenario where the
FFS application issues an AIO cancel call, while the UDC is handling a
soft disconnect.  For a DWC3 based implementation, the callstack looks
like the following:

    DWC3 Gadget                               FFS Application
dwc3_gadget_soft_disconnect()              ...
  --&gt; dwc3_stop_active_transfers()
    --&gt; dwc3_gadget_giveback(-ESHUTDOWN)
      --&gt; ffs_epfile_async_io_complete()   ffs_aio_cancel()
        --&gt; usb_ep_free_request()            --&gt; usb_ep_dequeue()

There is currently no locking implemented between the AIO completion
handler and AIO cancel, so the issue occurs if the completion routine is
running in parallel to an AIO cancel call coming from the FFS application.
As the completion call frees the USB request (io_data-&gt;req) the FFS
application is also referencing it for the usb_ep_dequeue() call.  This can
lead to accessing a stale/hanging pointer.

commit b566d38857fc ("usb: gadget: f_fs: use io_data-&gt;status consistently")
relocated the usb_ep_free_request() into ffs_epfile_async_io_complete().
However, in order to properly implement locking to mitigate this issue, the
spinlock can't be added to ffs_epfile_async_io_complete(), as
usb_ep_dequeue() (if successfully dequeuing a USB request) will call the
function driver's completion handler in the same context.  Hence, leading
into a deadlock.

Fix this issue by moving the usb_ep_free_request() back to
ffs_user_copy_worker(), and ensuring that it explicitly sets io_data-&gt;req
to NULL after freeing it within the ffs-&gt;eps_lock.  This resolves the race
condition above, as the ffs_aio_cancel() routine will not continue
attempting to dequeue a request that has already been freed, or the
ffs_user_copy_work() not freeing the USB request until the AIO cancel is
done referencing it.

This fix depends on
  commit b566d38857fc ("usb: gadget: f_fs: use io_data-&gt;status
  consistently")</Note>
    </Notes>
    <CVE>CVE-2024-36894</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: llcp: fix nfc_llcp_setsockopt() unsafe copies

syzbot reported unsafe calls to copy_from_sockptr() [1]

Use copy_safe_from_sockptr() instead.

[1]

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 nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255
Read of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078

CPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
  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
  copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
  copy_from_sockptr include/linux/sockptr.h:55 [inline]
  nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255
  do_sock_setsockopt+0x3b1/0x720 net/socket.c:2311
  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334
  __do_sys_setsockopt net/socket.c:2343 [inline]
  __se_sys_setsockopt net/socket.c:2340 [inline]
  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
 do_syscall_64+0xfd/0x240
 entry_SYSCALL_64_after_hwframe+0x6d/0x75
RIP: 0033:0x7f7fac07fd89
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 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:00007fff660eb788 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89
RDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004
RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000
R10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000</Note>
    </Notes>
    <CVE>CVE-2024-36915</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

block: fix overflow in blk_ioctl_discard()

There is no check for overflow of 'start + len' in blk_ioctl_discard().
Hung task occurs if submit an discard ioctl with the following param:
  start = 0x80000000000ff000, len = 0x8000000000fff000;
Add the overflow validation now.</Note>
    </Notes>
    <CVE>CVE-2024-36917</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fs/9p: fix uninitialized values during inode evict

If an iget fails due to not being able to retrieve information
from the server then the inode structure is only partially
initialized.  When the inode gets evicted, references to
uninitialized structures (like fscache cookies) were being
made.

This patch checks for a bad_inode before doing anything other
than clearing the inode from the cache.  Since the inode is
bad, it shouldn't have any state associated with it that needs
to be written back (and there really isn't a way to complete
those anyways).</Note>
    </Notes>
    <CVE>CVE-2024-36923</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: 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-36934</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue

Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which
syzbot reported [1].

[1]
BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue

write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1:
 sk_psock_stop_verdict net/core/skmsg.c:1257 [inline]
 sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843
 sk_psock_put include/linux/skmsg.h:459 [inline]
 sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648
 unix_release+0x4b/0x80 net/unix/af_unix.c:1048
 __sock_release net/socket.c:659 [inline]
 sock_close+0x68/0x150 net/socket.c:1421
 __fput+0x2c1/0x660 fs/file_table.c:422
 __fput_sync+0x44/0x60 fs/file_table.c:507
 __do_sys_close fs/open.c:1556 [inline]
 __se_sys_close+0x101/0x1b0 fs/open.c:1541
 __x64_sys_close+0x1f/0x30 fs/open.c:1541
 do_syscall_64+0xd3/0x1d0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0:
 sk_psock_data_ready include/linux/skmsg.h:464 [inline]
 sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555
 sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606
 sk_psock_verdict_apply net/core/skmsg.c:1008 [inline]
 sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202
 unix_read_skb net/unix/af_unix.c:2546 [inline]
 unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682
 sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223
 unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0x140/0x180 net/socket.c:745
 ____sys_sendmsg+0x312/0x410 net/socket.c:2584
 ___sys_sendmsg net/socket.c:2638 [inline]
 __sys_sendmsg+0x1e9/0x280 net/socket.c:2667
 __do_sys_sendmsg net/socket.c:2676 [inline]
 __se_sys_sendmsg net/socket.c:2674 [inline]
 __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674
 do_syscall_64+0xd3/0x1d0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

value changed: 0xffffffff83d7feb0 -&gt; 0x0000000000000000

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G        W          6.8.0-syzkaller-08951-gfe46a7dd189e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024

Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer
dereference in sk_psock_verdict_data_ready()") fixed one NULL pointer
similarly due to no protection of saved_data_ready. Here is another
different caller causing the same issue because of the same reason. So
we should protect it with sk_callback_lock read lock because the writer
side in the sk_psock_drop() uses "write_lock_bh(&amp;sk-&gt;sk_callback_lock);".

To avoid errors that could happen in future, I move those two pairs of
lock into the sk_psock_data_ready(), which is suggested by John Fastabend.</Note>
    </Notes>
    <CVE>CVE-2024-36938</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: delete incorrect free in pinctrl_enable()

The "pctldev" struct is allocated in devm_pinctrl_register_and_init().
It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),
so freeing it in pinctrl_enable() will lead to a double free.

The devm_pinctrl_dev_release() function frees the pindescs and destroys
the mutex as well.</Note>
    </Notes>
    <CVE>CVE-2024-36940</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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: nl80211: don't free NULL coalescing rule

If the parsing fails, we can dereference a NULL pointer here.</Note>
    </Notes>
    <CVE>CVE-2024-36941</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

amd/amdkfd: sync all devices to wait all processes being evicted

If there are more than one device doing reset in parallel, the first
device will call kfd_suspend_all_processes() to evict all processes
on all devices, this call takes time to finish. other device will
start reset and recover without waiting. if the process has not been
evicted before doing recover, it will be restored, then caused page
fault.</Note>
    </Notes>
    <CVE>CVE-2024-36949</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

firewire: ohci: mask bus reset interrupts between ISR and bottom half

In the FireWire OHCI interrupt handler, if a bus reset interrupt has
occurred, mask bus reset interrupts until bus_reset_work has serviced and
cleared the interrupt.

Normally, we always leave bus reset interrupts masked. We infer the bus
reset from the self-ID interrupt that happens shortly thereafter. A
scenario where we unmask bus reset interrupts was introduced in 2008 in
a007bb857e0b26f5d8b73c2ff90782d9c0972620: If
OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we
will unmask bus reset interrupts so we can log them.

irq_handler logs the bus reset interrupt. However, we can't clear the bus
reset event flag in irq_handler, because we won't service the event until
later. irq_handler exits with the event flag still set. If the
corresponding interrupt is still unmasked, the first bus reset will
usually freeze the system due to irq_handler being called again each
time it exits. This freeze can be reproduced by loading firewire_ohci
with "modprobe firewire_ohci debug=-1" (to enable all debugging output).
Apparently there are also some cases where bus_reset_work will get called
soon enough to clear the event, and operation will continue normally.

This freeze was first reported a few months after a007bb85 was committed,
but until now it was never fixed. The debug level could safely be set
to -1 through sysfs after the module was loaded, but this would be
ineffectual in logging bus reset interrupts since they were only
unmasked during initialization.

irq_handler will now leave the event flag set but mask bus reset
interrupts, so irq_handler won't be called again and there will be no
freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will
unmask the interrupt after servicing the event, so future interrupts
will be caught as desired.

As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be
enabled through sysfs in addition to during initial module loading.
However, when enabled through sysfs, logging of bus reset interrupts will
be effective only starting with the second bus reset, after
bus_reset_work has executed.</Note>
    </Notes>
    <CVE>CVE-2024-36950</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 invalid reads in fence signaled events

Correctly set the length of the drm_event to the size of the structure
that's actually used.

The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.</Note>
    </Notes>
    <CVE>CVE-2024-36960</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

fs/9p: only translate RWX permissions for plain 9P2000

Garbage in plain 9P2000's perm bits is allowed through, which causes it
to be able to set (among others) the suid bit. This was presumably not
the intent since the unix extended bits are handled explicitly and
conditionally on .u.</Note>
    </Notes>
    <CVE>CVE-2024-36964</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.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:

fpga: manager: add owner module and take its refcount

The current implementation of the fpga manager assumes that the low-level
module registers a driver for the parent device and uses its owner pointer
to take the module's refcount. This approach is problematic since it can
lead to a null pointer dereference while attempting to get the manager if
the parent device does not have a driver.

To address this problem, add a module owner pointer to the fpga_manager
struct and use it to take the module's refcount. Modify the functions for
registering the manager to take an additional owner module parameter and
rename them to avoid conflicts. Use the old function names for helper
macros that automatically set the module that registers the manager as the
owner. This ensures compatibility with existing low-level control modules
and reduces the chances of registering a manager without setting the owner.

Also, update the documentation to keep it consistent with the new interface
for registering an fpga manager.

Other changes: opportunistically move put_device() from __fpga_mgr_get() to
fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the
manager device is taken in these functions.</Note>
    </Notes>
    <CVE>CVE-2024-37021</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 crash on racing fsync and size-extending write into prealloc

We have been seeing crashes on duplicate keys in
btrfs_set_item_key_safe():

  BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)
  ------------[ cut here ]------------
  kernel BUG at fs/btrfs/ctree.c:2620!
  invalid opcode: 0000 [#1] PREEMPT SMP PTI
  CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
  RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]

With the following stack trace:

  #0  btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)
  #1  btrfs_drop_extents (fs/btrfs/file.c:411:4)
  #2  log_one_extent (fs/btrfs/tree-log.c:4732:9)
  #3  btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)
  #4  btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)
  #5  btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)
  #6  btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)
  #7  btrfs_sync_file (fs/btrfs/file.c:1933:8)
  #8  vfs_fsync_range (fs/sync.c:188:9)
  #9  vfs_fsync (fs/sync.c:202:9)
  #10 do_fsync (fs/sync.c:212:9)
  #11 __do_sys_fdatasync (fs/sync.c:225:9)
  #12 __se_sys_fdatasync (fs/sync.c:223:1)
  #13 __x64_sys_fdatasync (fs/sync.c:223:1)
  #14 do_syscall_x64 (arch/x86/entry/common.c:52:14)
  #15 do_syscall_64 (arch/x86/entry/common.c:83:7)
  #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)

So we're logging a changed extent from fsync, which is splitting an
extent in the log tree. But this split part already exists in the tree,
triggering the BUG().

This is the state of the log tree at the time of the crash, dumped with
drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)
to get more details than btrfs_print_leaf() gives us:

  &gt;&gt;&gt; print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"])
  leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610
  leaf 33439744 flags 0x100000000000000
  fs uuid e5bd3946-400c-4223-8923-190ef1f18677
  chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da
          item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160
                  generation 7 transid 9 size 8192 nbytes 8473563889606862198
                  block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0
                  sequence 204 flags 0x10(PREALLOC)
                  atime 1716417703.220000000 (2024-05-22 15:41:43)
                  ctime 1716417704.983333333 (2024-05-22 15:41:44)
                  mtime 1716417704.983333333 (2024-05-22 15:41:44)
                  otime 17592186044416.000000000 (559444-03-08 01:40:16)
          item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13
                  index 195 namelen 3 name: 193
          item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37
                  location key (0 UNKNOWN.0 0) type XATTR
                  transid 7 data_len 1 name_len 6
                  name: user.a
                  data a
          item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53
                  generation 9 type 1 (regular)
                  extent data disk byte 303144960 nr 12288
                  extent data offset 0 nr 4096 ram 12288
                  extent compression 0 (none)
          item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53
                  generation 9 type 2 (prealloc)
                  prealloc data disk byte 303144960 nr 12288
                  prealloc data offset 4096 nr 8192
          item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53
                  generation 9 type 2 (prealloc)
                  prealloc data disk byte 303144960 nr 12288
                  prealloc data offset 8192 nr 4096
  ...

So the real problem happened earlier: notice that items 4 (4k-12k) and 5
(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and
item 5 starts at i_size.

Here is the state of 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-37354</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In MIT Kerberos 5 (aka krb5) before 1.21.3, an attacker can modify the plaintext Extra Count field of a confidential GSS krb5 wrap token, causing the unwrapped token to appear truncated to the application.</Note>
    </Notes>
    <CVE>CVE-2024-37370</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:krb5-1.16.3-46.15.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:krb5-client-1.16.3-46.15.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 MIT Kerberos 5 (aka krb5) before 1.21.3, an attacker can cause invalid memory reads during GSS message token handling by sending message tokens with invalid length fields.</Note>
    </Notes>
    <CVE>CVE-2024-37371</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:krb5-1.16.3-46.15.1</ProductID>
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:krb5-client-1.16.3-46.15.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">url.c in GNU Wget through 1.24.5 mishandles semicolons in the userinfo subcomponent of a URI, and thus there may be insecure behavior in which data that was supposed to be in the userinfo subcomponent is misinterpreted to be part of the host subcomponent.</Note>
    </Notes>
    <CVE>CVE-2024-38428</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:wget-1.14-21.19.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt

In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the
resp_pkts queue and then a decision is made whether to run the completer
task inline or schedule it. Finally the skb is dereferenced to bump a 'hw'
performance counter. This is wrong because if the completer task is
already running in a separate thread it may have already processed the skb
and freed it which can cause a seg fault.  This has been observed
infrequently in testing at high scale.

This patch fixes this by changing the order of enqueuing the packet until
after the counter is accessed.</Note>
    </Notes>
    <CVE>CVE-2024-38544</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 UAF for cq async event

The refcount of CQ is not protected by locks. When CQ asynchronous
events and CQ destruction are concurrent, CQ may have been released,
which will cause UAF.

Use the xa_lock() to protect the CQ refcount.</Note>
    </Notes>
    <CVE>CVE-2024-38545</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 possible null pointer dereference

In vc4_hdmi_audio_init() of_get_address() may return
NULL which is later dereferenced. Fix this bug by adding NULL check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-38546</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/mediatek: Add 0 size check to mtk_drm_gem_obj

Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object
of 0 bytes. Currently, no such check exists and the kernel will panic if
a userspace application attempts to allocate a 0x0 GBM buffer.

Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and
verifying that we now return EINVAL.</Note>
    </Notes>
    <CVE>CVE-2024-38549</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential index out of bounds in color transformation function

Fixes index out of bounds issue in the color transformation 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, an error message is
logged and the function returns false to indicate an error.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_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:406 cm_helper_translate_curve_to_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:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf-&gt;tf_pts.blue' 1025 &lt;= s32max</Note>
    </Notes>
    <CVE>CVE-2024-38552</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: fec: remove .ndo_poll_controller to avoid deadlocks

There is a deadlock issue found in sungem driver, please refer to the
commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid
deadlocks"). The root cause of the issue is that netpoll is in atomic
context and disable_irq() is called by .ndo_poll_controller interface
of sungem driver, however, disable_irq() might sleep. After analyzing
the implementation of fec_poll_controller(), the fec driver should have
the same issue. Due to the fec driver uses NAPI for TX completions, the
.ndo_poll_controller is unnecessary to be implemented in the fec driver,
so fec_poll_controller() can be safely removed.</Note>
    </Notes>
    <CVE>CVE-2024-38553</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ar5523: enable proper endpoint verification

Syzkaller reports [1] hitting a warning about an endpoint in use
not having an expected type to it.

Fix the issue by checking for the existence of all proper
endpoints with their according types intact.

Sadly, this patch has not been tested on real hardware.

[1] Syzkaller report:
------------[ cut here ]------------
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
...
Call Trace:
 &lt;TASK&gt;
 ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275
 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline]
 ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline]
 ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655
 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396
 call_driver_probe drivers/base/dd.c:560 [inline]
 really_probe+0x249/0xb90 drivers/base/dd.c:639
 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778
 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808
 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936
 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427
 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008
 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487
 device_add+0xbd9/0x1e90 drivers/base/core.c:3517
 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170
 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238
 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293
 call_driver_probe drivers/base/dd.c:560 [inline]
 really_probe+0x249/0xb90 drivers/base/dd.c:639
 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778
 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808
 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936
 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427
 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008
 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487
 device_add+0xbd9/0x1e90 drivers/base/core.c:3517
 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573
 hub_port_connect drivers/usb/core/hub.c:5353 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5497 [inline]
 port_event drivers/usb/core/hub.c:5653 [inline]
 hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735
 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
 worker_thread+0x669/0x1090 kernel/workqueue.c:2436
 kthread+0x2e8/0x3a0 kernel/kthread.c:376
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-38565</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: carl9170: add a proper sanity check for endpoints

Syzkaller reports [1] hitting a warning which is caused by presence
of a wrong endpoint type at the URB sumbitting stage. While there
was a check for a specific 4th endpoint, since it can switch types
between bulk and interrupt, other endpoints are trusted implicitly.
Similar warning is triggered in a couple of other syzbot issues [2].

Fix the issue by doing a comprehensive check of all endpoints
taking into account difference between high- and full-speed
configuration.

[1] Syzkaller report:
...
WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
...
Call Trace:
 &lt;TASK&gt;
 carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504
 carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline]
 carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline]
 carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028
 request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107
 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
 worker_thread+0x669/0x1090 kernel/workqueue.c:2436
 kthread+0x2e8/0x3a0 kernel/kthread.c:376
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
 &lt;/TASK&gt;

[2] Related syzkaller crashes:</Note>
    </Notes>
    <CVE>CVE-2024-38567</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ecryptfs: Fix buffer size for tag 66 packet

The 'TAG 66 Packet Format' description is missing the cipher code and
checksum fields that are packed into the message packet. As a result,
the buffer allocated for the packet is 3 bytes too small and
write_tag_66_packet() will write up to 3 bytes past the end of the
buffer.

Fix this by increasing the size of the allocation so the whole packet
will always fit in the buffer.

This fixes the below kasan slab-out-of-bounds bug:

  BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0
  Write of size 1 at addr ffff88800afbb2a5 by task touch/181

  CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x4c/0x70
   print_report+0xc5/0x610
   ? ecryptfs_generate_key_packet_set+0x7d6/0xde0
   ? kasan_complete_mode_report_info+0x44/0x210
   ? ecryptfs_generate_key_packet_set+0x7d6/0xde0
   kasan_report+0xc2/0x110
   ? ecryptfs_generate_key_packet_set+0x7d6/0xde0
   __asan_store1+0x62/0x80
   ecryptfs_generate_key_packet_set+0x7d6/0xde0
   ? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10
   ? __alloc_pages+0x2e2/0x540
   ? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d]
   ? dentry_open+0x8f/0xd0
   ecryptfs_write_metadata+0x30a/0x550
   ? __pfx_ecryptfs_write_metadata+0x10/0x10
   ? ecryptfs_get_lower_file+0x6b/0x190
   ecryptfs_initialize_file+0x77/0x150
   ecryptfs_create+0x1c2/0x2f0
   path_openat+0x17cf/0x1ba0
   ? __pfx_path_openat+0x10/0x10
   do_filp_open+0x15e/0x290
   ? __pfx_do_filp_open+0x10/0x10
   ? __kasan_check_write+0x18/0x30
   ? _raw_spin_lock+0x86/0xf0
   ? __pfx__raw_spin_lock+0x10/0x10
   ? __kasan_check_write+0x18/0x30
   ? alloc_fd+0xf4/0x330
   do_sys_openat2+0x122/0x160
   ? __pfx_do_sys_openat2+0x10/0x10
   __x64_sys_openat+0xef/0x170
   ? __pfx___x64_sys_openat+0x10/0x10
   do_syscall_64+0x60/0xd0
   entry_SYSCALL_64_after_hwframe+0x6e/0xd8
  RIP: 0033:0x7f00a703fd67
  Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f
  RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
  RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67
  RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c
  RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000
  R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941
  R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040
   &lt;/TASK&gt;

  Allocated by task 181:
   kasan_save_stack+0x2f/0x60
   kasan_set_track+0x29/0x40
   kasan_save_alloc_info+0x25/0x40
   __kasan_kmalloc+0xc5/0xd0
   __kmalloc+0x66/0x160
   ecryptfs_generate_key_packet_set+0x6d2/0xde0
   ecryptfs_write_metadata+0x30a/0x550
   ecryptfs_initialize_file+0x77/0x150
   ecryptfs_create+0x1c2/0x2f0
   path_openat+0x17cf/0x1ba0
   do_filp_open+0x15e/0x290
   do_sys_openat2+0x122/0x160
   __x64_sys_openat+0xef/0x170
   do_syscall_64+0x60/0xd0
   entry_SYSCALL_64_after_hwframe+0x6e/0xd8</Note>
    </Notes>
    <CVE>CVE-2024-38578</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: bcm - Fix pointer arithmetic

In spu2_dump_omd() value of ptr is increased by ciph_key_len
instead of hash_iv_len which could lead to going beyond the
buffer boundaries.
Fix this bug by changing ciph_key_len to hash_iv_len.

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

epoll: be better about file lifetimes

epoll can call out to vfs_poll() with a file pointer that may race with
the last 'fput()'. That would make f_count go down to zero, and while
the ep-&gt;mtx locking means that the resulting file pointer tear-down will
be blocked until the poll returns, it means that f_count is already
dead, and any use of it won't actually get a reference to the file any
more: it's dead regardless.

Make sure we have a valid ref on the file pointer before we call down to
vfs_poll() from the epoll routines.</Note>
    </Notes>
    <CVE>CVE-2024-38580</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

eth: sungem: remove .ndo_poll_controller to avoid deadlocks

Erhard reports netpoll warnings from sungem:

  netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)
  WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c

gem_poll_controller() disables interrupts, which may sleep.
We can't sleep in netpoll, it has interrupts disabled completely.
Strangely, gem_poll_controller() doesn't even poll the completions,
and instead acts as if an interrupt has fired so it just schedules
NAPI and exits. None of this has been necessary for years, since
netpoll invokes NAPI directly.</Note>
    </Notes>
    <CVE>CVE-2024-38597</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix resync softlockup when bitmap size is less than array size

Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
trigger following softlockup:

kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
Call Trace:
 &lt;TASK&gt;
 md_bitmap_start_sync+0x6b/0xf0
 raid10_sync_request+0x25c/0x1b40 [raid10]
 md_do_sync+0x64b/0x1020
 md_thread+0xa7/0x170
 kthread+0xcf/0x100
 ret_from_fork+0x30/0x50
 ret_from_fork_asm+0x1a/0x30

And the detailed process is as follows:

md_do_sync
 j = mddev-&gt;resync_min
 while (j &lt; max_sectors)
  sectors = raid10_sync_request(mddev, j, &amp;skipped)
   if (!md_bitmap_start_sync(..., &amp;sync_blocks))
    // md_bitmap_start_sync set sync_blocks to 0
    return sync_blocks + sectors_skippe;
  // sectors = 0;
  j += sectors;
  // j never change

Root cause is that commit 301867b1c168 ("md/raid10: check
slab-out-of-bounds in md_bitmap_get_counter") return early from
md_bitmap_get_counter(), without setting returned blocks.

Fix this problem by always set returned blocks from
md_bitmap_get_counter"(), as it used to be.

Noted that this patch just fix the softlockup problem in kernel, the
case that bitmap size doesn't match array size still need to be fixed.</Note>
    </Notes>
    <CVE>CVE-2024-38598</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ring-buffer: Fix a race between readers and resize checks

The reader code in rb_get_reader_page() swaps a new reader page into the
ring buffer by doing cmpxchg on old-&gt;list.prev-&gt;next to point it to the
new page. Following that, if the operation is successful,
old-&gt;list.next-&gt;prev gets updated too. This means the underlying
doubly-linked list is temporarily inconsistent, page-&gt;prev-&gt;next or
page-&gt;next-&gt;prev might not be equal back to page for some page in the
ring buffer.

The resize operation in ring_buffer_resize() can be invoked in parallel.
It calls rb_check_pages() which can detect the described inconsistency
and stop further tracing:

[  190.271762] ------------[ cut here ]------------
[  190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0
[  190.271789] Modules linked in: [...]
[  190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1
[  190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G            E      6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f
[  190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014
[  190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0
[  190.272023] Code: [...]
[  190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206
[  190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80
[  190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700
[  190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000
[  190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720
[  190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000
[  190.272053] FS:  00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000
[  190.272057] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0
[  190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  190.272077] Call Trace:
[  190.272098]  &lt;TASK&gt;
[  190.272189]  ring_buffer_resize+0x2ab/0x460
[  190.272199]  __tracing_resize_ring_buffer.part.0+0x23/0xa0
[  190.272206]  tracing_resize_ring_buffer+0x65/0x90
[  190.272216]  tracing_entries_write+0x74/0xc0
[  190.272225]  vfs_write+0xf5/0x420
[  190.272248]  ksys_write+0x67/0xe0
[  190.272256]  do_syscall_64+0x82/0x170
[  190.272363]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[  190.272373] RIP: 0033:0x7f1bd657d263
[  190.272381] Code: [...]
[  190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[  190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263
[  190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001
[  190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000
[  190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500
[  190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002
[  190.272412]  &lt;/TASK&gt;
[  190.272414] ---[ end trace 0000000000000000 ]---

Note that ring_buffer_resize() calls rb_check_pages() only if the parent
trace_buffer has recording disabled. Recent commit d78ab792705c
("tracing: Stop current tracer when resizing buffer") causes that it is
now always the case which makes it more likely to experience this issue.

The window to hit this race is nonetheless very small. To help
reproducing it, one can add a delay loop in rb_get_reader_page():

 ret = rb_head_page_replace(reader, cpu_buffer-&gt;reader_page);
 if (!ret)
 	goto spin;
 for (unsigned i = 0; i &lt; 1U &lt;&lt; 26; i++)  /* inserted delay loop */
 	__asm__ __volatile__ ("" : : : "memory");
 rb_list_head(reader-&gt;list.next)-&gt;prev = &amp;cpu_buffer-&gt;reader_page-&gt;list;

.. 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-38601</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 netif state handling

mlx5e_suspend cleans resources only if netif_device_present() returns
true. However, mlx5e_resume changes the state of netif, via
mlx5e_nic_enable, only if reg_state == NETREG_REGISTERED.
In the below case, the above leads to NULL-ptr Oops[1] and memory
leaks:

mlx5e_probe
 _mlx5e_resume
  mlx5e_attach_netdev
   mlx5e_nic_enable  &lt;-- netdev not reg, not calling netif_device_attach()
  register_netdev &lt;-- failed for some reason.
ERROR_FLOW:
 _mlx5e_suspend &lt;-- netif_device_present return false, resources aren't freed :(

Hence, clean resources in this case as well.

[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 0 P4D 0
Oops: 0010 [#1] SMP
CPU: 2 PID: 9345 Comm: test-ovs-ct-gen Not tainted 6.5.0_for_upstream_min_debug_2023_09_05_16_01 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:0x0
Code: Unable to access opcode bytes at0xffffffffffffffd6.
RSP: 0018:ffff888178aaf758 EFLAGS: 00010246
Call Trace:
 &lt;TASK&gt;
 ? __die+0x20/0x60
 ? page_fault_oops+0x14c/0x3c0
 ? exc_page_fault+0x75/0x140
 ? asm_exc_page_fault+0x22/0x30
 notifier_call_chain+0x35/0xb0
 blocking_notifier_call_chain+0x3d/0x60
 mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core]
 mlx5_core_uplink_netdev_event_replay+0x3e/0x60 [mlx5_core]
 mlx5_mdev_netdev_track+0x53/0x60 [mlx5_ib]
 mlx5_ib_roce_init+0xc3/0x340 [mlx5_ib]
 __mlx5_ib_add+0x34/0xd0 [mlx5_ib]
 mlx5r_probe+0xe1/0x210 [mlx5_ib]
 ? auxiliary_match_id+0x6a/0x90
 auxiliary_bus_probe+0x38/0x80
 ? driver_sysfs_add+0x51/0x80
 really_probe+0xc9/0x3e0
 ? driver_probe_device+0x90/0x90
 __driver_probe_device+0x80/0x160
 driver_probe_device+0x1e/0x90
 __device_attach_driver+0x7d/0x100
 bus_for_each_drv+0x80/0xd0
 __device_attach+0xbc/0x1f0
 bus_probe_device+0x86/0xa0
 device_add+0x637/0x840
 __auxiliary_device_add+0x3b/0xa0
 add_adev+0xc9/0x140 [mlx5_core]
 mlx5_rescan_drivers_locked+0x22a/0x310 [mlx5_core]
 mlx5_register_device+0x53/0xa0 [mlx5_core]
 mlx5_init_one_devl_locked+0x5c4/0x9c0 [mlx5_core]
 mlx5_init_one+0x3b/0x60 [mlx5_core]
 probe_one+0x44c/0x730 [mlx5_core]
 local_pci_probe+0x3e/0x90
 pci_device_probe+0xbf/0x210
 ? kernfs_create_link+0x5d/0xa0
 ? sysfs_do_create_link_sd+0x60/0xc0
 really_probe+0xc9/0x3e0
 ? driver_probe_device+0x90/0x90
 __driver_probe_device+0x80/0x160
 driver_probe_device+0x1e/0x90
 __device_attach_driver+0x7d/0x100
 bus_for_each_drv+0x80/0xd0
 __device_attach+0xbc/0x1f0
 pci_bus_add_device+0x54/0x80
 pci_iov_add_virtfn+0x2e6/0x320
 sriov_enable+0x208/0x420
 mlx5_core_sriov_configure+0x9e/0x200 [mlx5_core]
 sriov_numvfs_store+0xae/0x1a0
 kernfs_fop_write_iter+0x10c/0x1a0
 vfs_write+0x291/0x3c0
 ksys_write+0x5f/0xe0
 do_syscall_64+0x3d/0x90
 entry_SYSCALL_64_after_hwframe+0x46/0xb0
 CR2: 0000000000000000
 ---[ end trace 0000000000000000  ]---</Note>
    </Notes>
    <CVE>CVE-2024-38608</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-storage: alauda: Check whether the media is initialized

The member "uzonesize" of struct alauda_info will remain 0
if alauda_init_media() fails, potentially causing divide errors
in alauda_read_data() and alauda_write_lba().
- Add a member "media_initialized" to struct alauda_info.
- Change a condition in alauda_check_media() to ensure the
  first initialization.
- Add an error check for the return value of alauda_init_media().</Note>
    </Notes>
    <CVE>CVE-2024-38619</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: stk1160: fix bounds checking in stk1160_copy_video()

The subtract in this condition is reversed.  The -&gt;length is the length
of the buffer.  The -&gt;bytesused is how many bytes we have copied thus
far.  When the condition is reversed that means the result of the
subtraction is always negative but since it's unsigned then the result
is a very high positive value.  That means the overflow check is never
true.

Additionally, the -&gt;bytesused doesn't actually work for this purpose
because we're not writing to "buf-&gt;mem + buf-&gt;bytesused".  Instead, the
math to calculate the destination where we are writing is a bit
involved.  You calculate the number of full lines already written,
multiply by two, skip a line if necessary so that we start on an odd
numbered line, and add the offset into the line.

To fix this buffer overflow, just take the actual destination where we
are writing, if the offset is already out of bounds print an error and
return.  Otherwise, write up to buf-&gt;length bytes.</Note>
    </Notes>
    <CVE>CVE-2024-38621</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

stm class: Fix a double free in stm_register_device()

The put_device(&amp;stm-&gt;dev) call will trigger stm_device_release() which
frees "stm" so the vfree(stm) on the next line is a double free.</Note>
    </Notes>
    <CVE>CVE-2024-38627</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

enic: Validate length of nl attributes in enic_set_vf_port

enic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE
is of length PORT_PROFILE_MAX and that the nl attributes
IFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX.
These attributes are validated (in the function do_setlink in rtnetlink.c)
using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE
as NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and
IFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation
using the policy is for the max size of the attributes and not on exact
size so the length of these attributes might be less than the sizes that
enic_set_vf_port expects. This might cause an out of bands
read access in the memcpys of the data of these
attributes in enic_set_vf_port.</Note>
    </Notes>
    <CVE>CVE-2024-38659</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ap: Fix crash in AP internal function modify_bitmap()

A system crash like this

  Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403
  Fault in home space mode while using kernel ASCE.
  AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d
  Oops: 0038 ilc:3 [#1] PREEMPT SMP
  Modules linked in: mlx5_ib ...
  CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8
  Hardware name: IBM 3931 A01 704 (LPAR)
  Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)
  R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
  Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3
  000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0
  000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff
  000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8
  Krnl Code: 0000014b75e7b5fc: a7840047            brc     8,0000014b75e7b68a
  0000014b75e7b600: 18b2                lr      %r11,%r2
  #0000014b75e7b602: a7f4000a            brc     15,0000014b75e7b616
  &gt;0000014b75e7b606: eb22d00000e6        laog    %r2,%r2,0(%r13)
  0000014b75e7b60c: a7680001            lhi     %r6,1
  0000014b75e7b610: 187b                lr      %r7,%r11
  0000014b75e7b612: 84960021            brxh    %r9,%r6,0000014b75e7b654
  0000014b75e7b616: 18e9                lr      %r14,%r9
  Call Trace:
  [&lt;0000014b75e7b606&gt;] ap_parse_bitmap_str+0x10e/0x1f8
  ([&lt;0000014b75e7b5dc&gt;] ap_parse_bitmap_str+0xe4/0x1f8)
  [&lt;0000014b75e7b758&gt;] apmask_store+0x68/0x140
  [&lt;0000014b75679196&gt;] kernfs_fop_write_iter+0x14e/0x1e8
  [&lt;0000014b75598524&gt;] vfs_write+0x1b4/0x448
  [&lt;0000014b7559894c&gt;] ksys_write+0x74/0x100
  [&lt;0000014b7618a440&gt;] __do_syscall+0x268/0x328
  [&lt;0000014b761a3558&gt;] system_call+0x70/0x98
  INFO: lockdep is turned off.
  Last Breaking-Event-Address:
  [&lt;0000014b75e7b636&gt;] ap_parse_bitmap_str+0x13e/0x1f8
  Kernel panic - not syncing: Fatal exception: panic_on_oops

occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value
(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.

The fix is simple: use unsigned long values for the internal variables. The
correct checks are already in place in the function but a simple int for
the internal variables was used with the possibility to overflow.</Note>
    </Notes>
    <CVE>CVE-2024-38661</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-buf/sw-sync: don't enable IRQ from sync_print_obj()

Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from
known context") by error replaced spin_unlock_irqrestore() with
spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite
sync_print_obj() is called from sync_debugfs_show(), lockdep complains
inconsistent lock state warning.

Use plain spin_{lock,unlock}() for sync_print_obj(), for
sync_debugfs_show() is already using spin_{lock,unlock}_irq().</Note>
    </Notes>
    <CVE>CVE-2024-38780</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 uninit-value in p9_client_rpc()

Syzbot with the help of KMSAN reported the following error:

BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]
BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
 trace_9p_client_res include/trace/events/9p.h:146 [inline]
 p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
 legacy_get_tree+0x114/0x290 fs/fs_context.c:662
 vfs_get_tree+0xa7/0x570 fs/super.c:1797
 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
 path_mount+0x742/0x1f20 fs/namespace.c:3679
 do_mount fs/namespace.c:3692 [inline]
 __do_sys_mount fs/namespace.c:3898 [inline]
 __se_sys_mount+0x725/0x810 fs/namespace.c:3875
 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

Uninit was created at:
 __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598
 __alloc_pages_node include/linux/gfp.h:238 [inline]
 alloc_pages_node include/linux/gfp.h:261 [inline]
 alloc_slab_page mm/slub.c:2175 [inline]
 allocate_slab mm/slub.c:2338 [inline]
 new_slab+0x2de/0x1400 mm/slub.c:2391
 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525
 __slab_alloc mm/slub.c:3610 [inline]
 __slab_alloc_node mm/slub.c:3663 [inline]
 slab_alloc_node mm/slub.c:3835 [inline]
 kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852
 p9_tag_alloc net/9p/client.c:278 [inline]
 p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641
 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688
 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
 legacy_get_tree+0x114/0x290 fs/fs_context.c:662
 vfs_get_tree+0xa7/0x570 fs/super.c:1797
 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
 path_mount+0x742/0x1f20 fs/namespace.c:3679
 do_mount fs/namespace.c:3692 [inline]
 __do_sys_mount fs/namespace.c:3898 [inline]
 __se_sys_mount+0x725/0x810 fs/namespace.c:3875
 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

If p9_check_errors() fails early in p9_client_rpc(), req-&gt;rc.tag
will not be properly initialized. However, trace_9p_client_res()
ends up trying to print it out anyway before p9_client_rpc()
finishes.

Fix this issue by assigning default values to p9_fcall fields
such as 'tag' and (just in case KMSAN unearths something new) 'id'
during the tag allocation stage.</Note>
    </Notes>
    <CVE>CVE-2024-39301</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: savage: Handle err return when savagefb_check_var failed

The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero")
checks the value of pixclock to avoid divide-by-zero error. However
the function savagefb_probe doesn't handle the error return of
savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.</Note>
    </Notes>
    <CVE>CVE-2024-39475</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:kernel-default-4.12.14-122.222.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </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">Issue summary: Calling the OpenSSL API function SSL_free_buffers may cause
memory to be accessed that was previously freed in some situations

Impact summary: A use after free can have a range of potential consequences such
as the corruption of valid data, crashes or execution of arbitrary code.
However, only applications that directly call the SSL_free_buffers function are
affected by this issue. Applications that do not call this function are not
vulnerable. Our investigations indicate that this function is rarely used by
applications.

The SSL_free_buffers function is used to free the internal OpenSSL buffer used
when processing an incoming record from the network. The call is only expected
to succeed if the buffer is not currently in use. However, two scenarios have
been identified where the buffer is freed even when still in use.

The first scenario occurs where a record header has been received from the
network and processed by OpenSSL, but the full record body has not yet arrived.
In this case calling SSL_free_buffers will succeed even though a record has only
been partially processed and the buffer is still in use.

The second scenario occurs where a full record containing application data has
been received and processed by OpenSSL but the application has only read part of
this data. Again a call to SSL_free_buffers will succeed even though the buffer
is still in use.

While these scenarios could occur accidentally during normal operation a
malicious attacker could attempt to engineer a stituation where this occurs.
We are not aware of this issue being actively exploited.

The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.</Note>
    </Notes>
    <CVE>CVE-2024-4741</CVE>
    <ProductStatuses>
      <Status Type="Fixed">
        <ProductID>Public Cloud Image google/sles-12-sp5-byos-v20240727-x86-64:libopenssl1_1-1.1.1d-2.107.1</ProductID>
      </Status>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
</cvrfdoc>
