<?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:888-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:888-1</ID>
    </Identification>
    <Status>Interim</Status>
    <Version>1</Version>
    <RevisionHistory>
      <Revision>
        <Number>1</Number>
        <Date>2025-02-21T13:27:48Z</Date>
        <Description>current</Description>
      </Revision>
    </RevisionHistory>
    <InitialReleaseDate>2024-08-08T01:00:00Z</InitialReleaseDate>
    <CurrentReleaseDate>2024-08-08T01: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:888-1 / google/sles-sap-15-sp5-hardened-v20240808-x86-64</Note>
    <Note Title="Details" Type="General" Ordinal="2" xml:lang="en">This image update for google/sles-sap-15-sp5-hardened-v20240808-x86-64 contains the following changes:
Package SAPHanaSR was updated:

- Version bump to 0.162.4  * unify global.ini examples
  * add demo script SAPHanaSR-upgrade-to-angi-demo
  * update man pages:
    SAPHanaSR_basic_cluster.7
    SAPHanaSR_maintenance_examples.7
    SAPHanaSR_upgrade_to_angi.7
    SAPHanaSR-manageProvider.8
    SAPHanaSR-upgrade-to-angi-demo.8
    SAPHanaSR.py.7

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

Package aaa_base was updated:

- modify git-47-04210f8df15da0ba4d741cfe1693af06f5978a1d.patch  to also fix the typo to set JAVA_BINDIR in the csh variant
  of the alljava profile script (bsc#1221361)

Package autofs was updated:

- autofs-5.1.6-remove-intr-hosts-map-mount-option.patch  Don't use the intr option on NFS mounts by default, it's been
  ignored by the kernel for a long time now. (bsc#1225130)

Package chrony was updated:

- Use make quickcheck instead of make check to avoid &amp;gt;1h build  times and failures due to timeouts. This was the default before
  3.2 but it changed to make tests more reliable. Here a seed is
  already set to get deterministic execution.

- Use shorter NTS-KE retry interval when network is down
  (bsc#1213551, chrony-burst_total_samples_to_go.patch,
  chrony-retry_interval_ke_start.patch).

Package cloud-regionsrv-client was updated:

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

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

Package kernel-default was updated:

- usb: typec: ucsi: Limit read size on v1.2 (CVE-2024-35924  bsc#1224657).
- commit 578815c

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

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

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

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

- Update references
- commit 006ab15

- kABI: bpf: struct bpf_insn_aux_data kABI workaround
  (bsc#1225756).
- commit b5b7cd0

- bpf: Protect against int overflow for stack access size
  (bsc#1224488 CVE-2024-35905).
- commit 1edb341

- vhost-vdpa: fix use after free in vhost_vdpa_probe()
  (CVE-2023-52795 bsc#1225085).
- commit 423f910

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

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

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

- Update
  patches.suse/scsi-core-Fix-unremoved-procfs-host-directory-regression.patch
  (git-fixes bsc#1223675 CVE-2024-269355).
  Adding the CVE references.
- commit 2df316d

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

- bpf: remove unnecessary prune and jump points (bsc#1225756).
- bpf: mostly decouple jump history management from
  is_state_visited() (bsc#1225756).
- bpf: decouple prune and jump points (bsc#1225756).
- commit 574a67d

- Refresh patches.suse/swiotlb-Fix-double-allocation-of-slots-due-to-broken-alignment-handling.patch
  This fixes following build warning:
  Changed build warnings:
  * **** 1 warnings *****
  * comparison of distinct pointer types lacks a cast in ../kernel/dma/swiotlb.c in swiotlb_do_find_slots (from ../include/linux/minmax.h)
  In file included from ../include/linux/kernel.h:17:0,
  ../kernel/dma/swiotlb.c: In function 'swiotlb_do_find_slots':
  ../include/linux/minmax.h:20:28: warning: comparison of distinct pointer types lacks a cast
  ../include/linux/minmax.h:26:4: note: in expansion of macro '__typecheck'
  ../include/linux/minmax.h:36:24: note: in expansion of macro '__safe_cmp'
  ../include/linux/minmax.h:52:19: note: in expansion of macro '__careful_cmp'
  ../kernel/dma/swiotlb.c:648:12: note: in expansion of macro 'max'
- commit a52b0ca

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

- bpf: handle ldimm64 properly in check_cfg() (bsc#1225756).
- commit 7a7f193

- blacklist.conf: added fix that needs code not present
- commit 9671fd4

- smb: client: set correct id, uid and cruid for multiuser
  automounts (bsc#1223011, CVE-2024-26822).
- commit 04cc660

- smb3: missing lock when picking channel (bsc#1224020,
  bsc#1224550, CVE-2024-35999).
- commit dfca6b0

- smb: client: fix potential UAF in
  cifs_signal_cifsd_for_reconnect() (bsc#1224020, bsc#1224766,
  CVE-2024-35861).
- commit 40c4ccf

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

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

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

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

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

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

- smb: client: fix potential UAF in cifs_dump_full_key()
  (bsc#1224020, bsc#1224667, CVE-2024-35866).
- commit f99c74f

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

- smb: client: guarantee refcounted children from parent session
  (bsc#1224020, bsc#1224679, CVE-2024-35869).
- commit 6773173

- smb: client: fix UAF in smb2_reconnect_server() (bsc#1224020,
  bsc#1224672, CVE-2024-35870).
- commit 69f157e

- cifs: failure to add channel on iface should bump up weight
  (git-fixes, bsc#1224020).
- commit f21b7f9

- Revert &amp;quot;cifs: reconnect work should have reference on server
  struct&amp;quot; (git-fixes, bsc#1224020).
- commit 04d1a0e

- cifs: fix leak of iface for primary channel (git-fixes,
  bsc#1224020).
- commit 0af0c46

- smb: client: fix mount when dns_resolver key is not available
  (git-fixes, bsc#1224020).
- commit 751b43e

- cifs: handle cases where multiple sessions share connection
  (bsc#1224020).
- commit caf101a

- smb3: show beginning time for per share stats (bsc#1224020).
- commit 9120f21

- cifs: cifs_chan_is_iface_active should be called with chan_lock
  held (bsc#1224020).
- commit 8eaf345

- cifs: do not pass cifs_sb when trying to add channels
  (bsc#1224020).
- commit 0be08c0

- smb: client: remove extra @chan_count check in
  __cifs_put_smb_ses() (bsc#1224020).
- commit 48869a9

- cifs: reconnect work should have reference on server struct
  (bsc#1224020).
- commit 4099f48

- cifs: handle cases where a channel is closed (bsc#1224020).
- commit 856c9d4

- smb: client: reduce stack usage in cifs_try_adding_channels()
  (bsc#1224020).
- commit 664baaf

- smb: client: get rid of dfs code dep in namespace.c
  (bsc#1224020).
- commit fd4a262

- smb: client: get rid of dfs naming in automount code
  (bsc#1224020).
- commit ffae390

- smb: client: rename cifs_dfs_ref.c to namespace.c (bsc#1224020).
- commit 28e987f

- smb: client: ensure to try all targets when finding nested links
  (bsc#1224020).
- commit af0feb9

- smb: client: introduce DFS_CACHE_TGT_LIST() (bsc#1224020).
- commit ba31c72

- cifs: fix charset issue in reconnection (bsc#1224020).
- commit 18aa95e

- cifs: account for primary channel in the interface list
  (bsc#1224020).
- commit a4889d1

- smb: Fix regression in writes when non-standard maximum write
  size negotiated (bsc#1222464, CVE-2024-26692).
- commit 3c009aa

- cifs: distribute channels across interfaces based on speed
  (bsc#1224020).
- commit 607d036

- Update
  patches.suse/ACPI-processor_idle-Fix-memory-leak-in-acpi_processo.patch
  (git-fixes CVE-2024-26894 bsc#1223043).
- Update
  patches.suse/ALSA-hda-intel-sdw-acpi-fix-usage-of-device_get_name.patch
  (git-fixes CVE-2024-36955 bsc#1225810).
- Update
  patches.suse/ALSA-usb-audio-Stop-parsing-channels-bits-when-all-c.patch
  (git-fixes CVE-2024-27436 bsc#1224803).
- Update
  patches.suse/ARM-9381-1-kasan-clear-stale-stack-poison.patch
  (git-fixes CVE-2024-36906 bsc#1225715).
- Update
  patches.suse/Bluetooth-Avoid-potential-use-after-free-in-hci_erro.patch
  (git-fixes CVE-2024-26801 bsc#1222413).
- Update
  patches.suse/Bluetooth-Fix-memory-leak-in-hci_req_sync_complete.patch
  (git-fixes CVE-2024-35978 bsc#1224571).
- Update
  patches.suse/Bluetooth-L2CAP-Fix-not-validating-setsockopt-user-i.patch
  (git-fixes CVE-2024-35965 bsc#1224579).
- Update
  patches.suse/Bluetooth-RFCOMM-Fix-not-validating-setsockopt-user-.patch
  (git-fixes CVE-2024-35966 bsc#1224576).
- Update
  patches.suse/Bluetooth-SCO-Fix-not-validating-setsockopt-user-inp.patch
  (git-fixes CVE-2024-35967 bsc#1224587).
- Update
  patches.suse/Bluetooth-btintel-Fix-null-ptr-deref-in-btintel_read.patch
  (stable-fixes CVE-2024-35933 bsc#1224640).
- Update
  patches.suse/Bluetooth-hci_event-Fix-handling-of-HCI_EV_IO_CAPA_R.patch
  (git-fixes CVE-2024-27416 bsc#1224723).
- Update
  patches.suse/Bluetooth-hci_sock-Fix-not-validating-setsockopt-use.patch
  (git-fixes CVE-2024-35963 bsc#1224582).
- Update
  patches.suse/Bluetooth-l2cap-fix-null-ptr-deref-in-l2cap_chan_tim.patch
  (git-fixes CVE-2024-27399 bsc#1224177).
- Update
  patches.suse/Bluetooth-msft-fix-slab-use-after-free-in-msft_do_cl.patch
  (git-fixes CVE-2024-36012 bsc#1225502).
- Update
  patches.suse/Bluetooth-qca-add-missing-firmware-sanity-checks.patch
  (git-fixes CVE-2024-36880 bsc#1225722).
- Update
  patches.suse/Bluetooth-qca-fix-NULL-deref-on-non-serdev-suspend.patch
  (git-fixes CVE-2024-35851 bsc#1224509).
- Update
  patches.suse/Bluetooth-qca-fix-info-leak-when-fetching-fw-build-i.patch
  (git-fixes CVE-2024-36032 bsc#1225720).
- Update
  patches.suse/IB-hfi1-Fix-a-memleak-in-init_credit_return.patch
  (git-fixes CVE-2024-26839 bsc#1222975).
- Update
  patches.suse/NFSv4.2-fix-nfs4_listxattr-kernel-BUG-at-mm-usercopy.patch
  (git-fixes CVE-2024-26870 bsc#1223113).
- Update
  patches.suse/PCI-PM-Drain-runtime-idle-callbacks-before-driver-re.patch
  (git-fixes CVE-2024-35809 bsc#1224738).
- Update
  patches.suse/RDMA-irdma-Fix-KASAN-issue-with-tasklet.patch
  (git-fixes CVE-2024-26838 bsc#1222974).
- Update
  patches.suse/RDMA-mlx5-Fix-fortify-source-warning-while-accessing.patch
  (git-fixes CVE-2024-26907 bsc#1223203).
- Update
  patches.suse/Revert-drm-amd-flush-any-delayed-gfxoff-on-suspend-e.patch
  (git-fixes CVE-2024-26916 bsc#1223137).
- Update
  patches.suse/SUNRPC-fix-some-memleaks-in-gssx_dec_option_array.patch
  (git-fixes CVE-2024-27388 bsc#1223744).
- Update
  patches.suse/USB-core-Fix-access-violation-during-port-device-rem.patch
  (git-fixes CVE-2024-36896 bsc#1225734).
- Update
  patches.suse/USB-core-Fix-deadlock-in-usb_deauthorize_interface.patch
  (git-fixes CVE-2024-26934 bsc#1223671).
- Update
  patches.suse/arm64-hibernate-Fix-level3-translation-fault-in-swsu.patch
  (git-fixes CVE-2024-26989 bsc#1223748).
- Update
  patches.suse/ax25-fix-use-after-free-bugs-caused-by-ax25_ds_del_t.patch
  (git-fixes CVE-2024-35887 bsc#1224663).
- Update
  patches.suse/batman-adv-Avoid-infinite-loop-trying-to-resize-loca.patch
  (git-fixes CVE-2024-35982 bsc#1224566).
- Update patches.suse/bpf-Check-bloom-filter-map-value-size.patch
  (bsc#1224488 CVE-2024-35905 CVE-2024-36918 bsc#1225766).
- Update
  patches.suse/btrfs-fix-information-leak-in-btrfs_ioctl_logical_to.patch
  (git-fixes CVE-2024-35849 bsc#1224733).
- Update
  patches.suse/clk-Get-runtime-PM-before-walking-tree-during-disabl.patch
  (git-fixes CVE-2024-27004 bsc#1223762).
- Update
  patches.suse/clk-zynq-Prevent-null-pointer-dereference-caused-by-.patch
  (git-fixes CVE-2024-27037 bsc#1223717).
- Update
  patches.suse/comedi-vmk80xx-fix-incomplete-endpoint-checking.patch
  (git-fixes CVE-2024-27001 bsc#1223698).
- Update
  patches.suse/cpufreq-brcmstb-avs-cpufreq-add-check-for-cpufreq_cp.patch
  (git-fixes CVE-2024-27051 bsc#1223769).
- Update
  patches.suse/crypto-qat-resolve-race-condition-during-AER-recover.patch
  (git-fixes CVE-2024-26974 bsc#1223638).
- Update
  patches.suse/dm-call-the-resume-method-on-internal-suspend-65e8.patch
  (git-fixes CVE-2024-26880 bsc#1223188).
- Update patches.suse/dma-xilinx_dpdma-Fix-locking.patch
  (git-fixes CVE-2024-35990 bsc#1224559).
- Update
  patches.suse/dmaengine-fsl-qdma-Fix-a-memory-leak-related-to-the-.patch
  (git-fixes CVE-2024-35833 bsc#1224632).
- Update
  patches.suse/dmaengine-fsl-qdma-init-irq-after-reg-initialization.patch
  (git-fixes CVE-2024-26788 bsc#1222783).
- Update
  patches.suse/dmaengine-idxd-Fix-oops-during-rmmod-on-single-CPU-p.patch
  (git-fixes CVE-2024-35989 bsc#1224558).
- Update
  patches.suse/drm-amd-display-Atom-Integrated-System-Info-v2_2-for.patch
  (stable-fixes CVE-2024-36897 bsc#1225735).
- Update
  patches.suse/drm-amd-display-Fix-a-potential-buffer-overflow-in-d.patch
  (git-fixes CVE-2024-27045 bsc#1223826).
- Update
  patches.suse/drm-amd-pm-fixes-a-random-hang-in-S4-for-SMU-v13.0.4.patch
  (stable-fixes CVE-2024-36026 bsc#1225705).
- Update
  patches.suse/drm-amdgpu-once-more-fix-the-call-oder-in-amdgpu_ttm.patch
  (git-fixes CVE-2024-27400 bsc#1224180).
- Update
  patches.suse/drm-amdgpu-validate-the-parameters-of-bo-mapping-ope.patch
  (git-fixes CVE-2024-26922 bsc#1223315).
- Update
  patches.suse/drm-arm-malidp-fix-a-possible-null-pointer-dereferen.patch
  (git-fixes CVE-2024-36014 bsc#1225593).
- Update patches.suse/drm-ast-Fix-soft-lockup.patch (git-fixes
  CVE-2024-35952 bsc#1224705).
- Update
  patches.suse/drm-client-Fully-protect-modes-with-dev-mode_config..patch
  (stable-fixes CVE-2024-35950 bsc#1224703).
- Update
  patches.suse/drm-i915-bios-Tolerate-devdata-NULL-in-intel_bios_en.patch
  (stable-fixes CVE-2024-26938 bsc#1223678).
- Update
  patches.suse/drm-i915-gt-Reset-queue_priority_hint-on-parking.patch
  (git-fixes CVE-2024-26937 bsc#1223677).
- Update
  patches.suse/drm-lima-fix-a-memleak-in-lima_heap_alloc.patch
  (git-fixes CVE-2024-35829 bsc#1224707).
- Update
  patches.suse/drm-mediatek-Fix-a-null-pointer-crash-in-mtk_drm_crt.patch
  (git-fixes CVE-2024-26874 bsc#1223048).
- Update patches.suse/drm-nv04-Fix-out-of-bounds-access.patch
  (git-fixes CVE-2024-27008 bsc#1223802).
- Update
  patches.suse/drm-vc4-don-t-check-if-plane-state-fb-state-fb.patch
  (stable-fixes CVE-2024-35932 bsc#1224650).
- Update
  patches.suse/drm-vmwgfx-Create-debugfs-ttm_resource_manager-entry.patch
  (git-fixes CVE-2024-26940 bsc#1223718).
- Update
  patches.suse/dyndbg-fix-old-BUG_ON-in-control-parser.patch
  (stable-fixes CVE-2024-35947 bsc#1224647).
- Update
  patches.suse/fbdev-savage-Error-out-if-pixclock-equals-zero.patch
  (git-fixes CVE-2024-26778 bsc#1222770).
- Update
  patches.suse/fbdev-sis-Error-out-if-pixclock-equals-zero.patch
  (git-fixes CVE-2024-26777 bsc#1222765).
- Update
  patches.suse/fbmon-prevent-division-by-zero-in-fb_videomode_from_.patch
  (stable-fixes CVE-2024-35922 bsc#1224660).
- Update
  patches.suse/i2c-smbus-fix-NULL-function-pointer-dereference.patch
  (git-fixes CVE-2024-35984 bsc#1224567).
- Update
  patches.suse/init-main.c-Fix-potential-static_command_line-memory.patch
  (git-fixes CVE-2024-26988 bsc#1223747).
- Update
  patches.suse/irqchip-gic-v3-its-Prevent-double-free-on-error.patch
  (git-fixes CVE-2024-35847 bsc#1224697).
- Update
  patches.suse/kprobes-Fix-possible-use-after-free-issue-on-kprobe-registration.patch
  (git-fixes CVE-2024-35955 bsc#1224676).
- Update
  patches.suse/media-dvb-frontends-avoid-stack-overflow-warnings-wi.patch
  (git-fixes CVE-2024-27075 bsc#1223842).
- Update
  patches.suse/media-go7007-fix-a-memleak-in-go7007_load_encoder.patch
  (git-fixes CVE-2024-27074 bsc#1223844).
- Update
  patches.suse/media-imx-csc-scaler-fix-v4l2_ctrl_handler-memory-le.patch
  (git-fixes CVE-2024-27076 bsc#1223779).
- Update patches.suse/media-ir_toy-fix-a-memleak-in-irtoy_tx.patch
  (git-fixes CVE-2024-26829 bsc#1223027).
- Update
  patches.suse/media-ttpci-fix-two-memleaks-in-budget_av_attach.patch
  (git-fixes CVE-2024-27073 bsc#1223843).
- Update
  patches.suse/media-usbtv-Remove-useless-locks-in-usbtv_video_free.patch
  (git-fixes CVE-2024-27072 bsc#1223837).
- Update
  patches.suse/media-v4l2-mem2mem-fix-a-memleak-in-v4l2_m2m_registe.patch
  (git-fixes CVE-2024-27077 bsc#1223780).
- Update
  patches.suse/media-v4l2-tpg-fix-some-memleaks-in-tpg_alloc.patch
  (git-fixes CVE-2024-27078 bsc#1223781).
- Update
  patches.suse/mmc-core-Avoid-negative-index-with-array-access.patch
  (git-fixes CVE-2024-35813 bsc#1224618).
- Update
  patches.suse/mmc-sdhci-msm-pervent-access-to-suspended-controller.patch
  (git-fixes CVE-2024-36029 bsc#1225708).
- Update
  patches.suse/msft-hv-2940-hv_netvsc-Fix-race-condition-between-netvsc_probe-an.patch
  (git-fixes CVE-2024-26698 bsc#1222374).
- Update
  patches.suse/msft-hv-2971-net-mana-Fix-Rx-DMA-datasize-and-skb_over_panic.patch
  (git-fixes CVE-2024-35901 bsc#1224495).
- Update
  patches.suse/net-bnx2x-Prevent-access-to-a-freed-page-in-page_poo.patch
  (bsc#1215322 CVE-2024-26859 bsc#1223049).
- Update
  patches.suse/net-ll_temac-platform_get_resource-replaced-by-wrong.patch
  (git-fixes CVE-2024-35796 bsc#1224615).
- Update
  patches.suse/net-phy-fix-phy_get_internal_delay-accessing-an-empt.patch
  (git-fixes CVE-2024-27047 bsc#1223828).
- Update
  patches.suse/net-qualcomm-rmnet-fix-global-oob-in-rmnet_policy.patch
  (git-fixes CVE-2024-26597 bsc#1220363).
- Update
  patches.suse/nfc-nci-Fix-uninit-value-in-nci_dev_up-and-nci_ntf_p.patch
  (git-fixes CVE-2024-35915 bsc#1224479).
- Update
  patches.suse/nouveau-fix-instmem-race-condition-around-ptr-stores.patch
  (git-fixes CVE-2024-26984 bsc#1223633).
- Update
  patches.suse/nvme-fc-do-not-wait-in-vain-when-unloading-module.patch
  (git-fixes CVE-2024-26846 bsc#1223023).
- Update
  patches.suse/nvme-fix-reconnection-fail-due-to-reserved-tag-alloc.patch
  (git-fixes CVE-2024-27435 bsc#1224717).
- Update patches.suse/pci_iounmap-Fix-MMIO-mapping-leak.patch
  (git-fixes CVE-2024-26977 bsc#1223631).
- Update
  patches.suse/power-supply-bq27xxx-i2c-Do-not-free-non-existing-IR.patch
  (git-fixes CVE-2024-27412 bsc#1224437).
- Update
  patches.suse/powerpc-pseries-iommu-LPAR-panics-during-boot-up-wit.patch
  (bsc#1222011 ltc#205900 CVE-2024-36926 bsc#1225829).
- Update
  patches.suse/ppdev-Add-an-error-check-in-register_device.patch
  (git-fixes CVE-2024-36015 bsc#1225640).
- Update
  patches.suse/pstore-zone-Add-a-null-pointer-check-to-the-psz_kmsg.patch
  (stable-fixes CVE-2024-35940 bsc#1224537).
- 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/s390-cio-Ensure-the-copied-buf-is-NUL-terminated.patch
  (git-fixes bsc#1223875 CVE-2024-36931 bsc#1225747).
- Update
  patches.suse/s390-qeth-Fix-kernel-panic-after-setting-hsuid.patch
  (git-fixes bsc#1223879 CVE-2024-36928 bsc#1225775).
- Update
  patches.suse/s390-zcrypt-fix-reference-counting-on-zcrypt-card-objects.patch
  (git-fixes bsc#1223595 CVE-2024-26957 bsc#1223666).
- Update
  patches.suse/scsi-lpfc-Fix-possible-memory-leak-in-lpfc_rcv_padis.patch
  (bsc#1220021 CVE-2024-35930 bsc#1224651).
- Update
  patches.suse/scsi-lpfc-Release-hbalock-before-calling-lpfc_worker.patch
  (bsc#1221777 CVE-2024-36924 bsc#1225820).
- 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-pointer.patch
  (bsc1221816 CVE-2024-26930 bsc#1223626).
- Update
  patches.suse/serial-mxs-auart-add-spinlock-around-changing-cts-st.patch
  (git-fixes CVE-2024-27000 bsc#1223757).
- Update
  patches.suse/serial-pmac_zilog-Remove-flawed-mitigation-for-rx-ir.patch
  (git-fixes CVE-2024-26999 bsc#1223754).
- Update
  patches.suse/soc-fsl-qbman-Always-disable-interrupts-when-taking-.patch
  (git-fixes CVE-2024-35806 bsc#1224699).
- Update patches.suse/speakup-Avoid-crash-on-very-long-word.patch
  (git-fixes CVE-2024-26994 bsc#1223750).
- Update
  patches.suse/spi-spi-mt65xx-Fix-NULL-pointer-access-in-interrupt-.patch
  (git-fixes CVE-2024-27028 bsc#1223788).
- Update
  patches.suse/tty-n_gsm-fix-possible-out-of-bounds-in-gsm0_receive.patch
  (git-fixes CVE-2024-36016 bsc#1225642).
- Update
  patches.suse/ubifs-Set-page-uptodate-in-the-correct-place.patch
  (git-fixes CVE-2024-35821 bsc#1224629).
- Update
  patches.suse/usb-cdc-wdm-close-race-between-read-and-workqueue.patch
  (git-fixes CVE-2024-35812 bsc#1224624).
- Update
  patches.suse/usb-cdns3-fix-memory-double-free-when-handle-zero-pa.patch
  (git-fixes CVE-2024-26748 bsc#1222513).
- Update
  patches.suse/usb-dwc2-host-Fix-dereference-issue-in-DDMA-completi.patch
  (git-fixes CVE-2024-26997 bsc#1223741).
- Update
  patches.suse/usb-gadget-f_ncm-Fix-UAF-ncm-object-at-re-bind-after.patch
  (stable-fixes CVE-2024-26996 bsc#1223752).
- Update
  patches.suse/usb-gadget-ncm-Avoid-dropping-datagrams-of-properly-.patch
  (git-fixes CVE-2024-27405 bsc#1224423).
- Update
  patches.suse/usb-gadget-ncm-Fix-handling-of-zero-block-length-pac.patch
  (git-fixes CVE-2024-35825 bsc#1224681).
- Update
  patches.suse/usb-typec-tcpm-Check-for-port-partner-validity-befor.patch
  (git-fixes CVE-2024-36893 bsc#1225748).
- Update
  patches.suse/usb-udc-remove-warning-when-queue-disabled-ep.patch
  (stable-fixes CVE-2024-35822 bsc#1224739).
- Update
  patches.suse/usb-xhci-Add-error-handling-in-xhci_map_urb_for_dma.patch
  (git-fixes CVE-2024-26964 bsc#1223650).
- Update
  patches.suse/vt-fix-unicode-buffer-corruption-when-deleting-chara.patch
  (git-fixes CVE-2024-35823 bsc#1224692).
- Update
  patches.suse/wifi-ath11k-decrease-MHI-channel-buffer-length-to-8K.patch
  (bsc#1207948 CVE-2024-35938 bsc#1224643).
- Update
  patches.suse/wifi-iwlwifi-dbg-tlv-ensure-NUL-termination.patch
  (git-fixes CVE-2024-35845 bsc#1224731).
- Update
  patches.suse/wifi-iwlwifi-mvm-rfi-fix-potential-response-leaks.patch
  (git-fixes CVE-2024-35912 bsc#1224487).
- Update
  patches.suse/wifi-libertas-fix-some-memleaks-in-lbs_allocate_cmd_.patch
  (git-fixes CVE-2024-35828 bsc#1224622).
- Update
  patches.suse/wifi-mac80211-check-clear-fast-rx-for-non-4addr-sta-.patch
  (stable-fixes CVE-2024-35789 bsc#1224749).
- Update
  patches.suse/wifi-nl80211-don-t-free-NULL-coalescing-rule.patch
  (git-fixes CVE-2024-36941 bsc#1225835).
- Update
  patches.suse/wifi-nl80211-reject-iftype-change-with-mesh-ID-chang.patch
  (git-fixes CVE-2024-27410 bsc#1224432).
- Update
  patches.suse/wifi-rtl8xxxu-add-cancel_work_sync-for-c2hcmd_work.patch
  (git-fixes CVE-2024-27052 bsc#1223829).
- Update
  patches.suse/wifi-wilc1000-fix-RCU-usage-in-connect-path.patch
  (git-fixes CVE-2024-27053 bsc#1223737).
- Update
  patches.suse/x86-fpu-Keep-xfd_state-in-sync-with-MSR_IA32_XFD.patch
  (git-fixes CVE-2024-35801 bsc#1224732).
- commit aea06f9

- Update
  patches.suse/ACPI-LPIT-Avoid-u32-multiplication-overflow.patch
  (git-fixes CVE-2023-52683 bsc#1224627).
- Update
  patches.suse/ACPI-video-check-for-error-while-searching-for-backl.patch
  (git-fixes CVE-2023-52693 bsc#1224686).
- Update
  patches.suse/IB-mlx5-Fix-init-stage-error-handling-to-avoid-doubl.patch
  (git-fixes CVE-2023-52851 bsc#1225587).
- Update
  patches.suse/Revert-drm-amd-pm-resolve-reboot-exception-for-si-ol.patch
  (git-fixes CVE-2023-52657 bsc#1224722).
- Update
  patches.suse/SUNRPC-Fix-RPC-client-cleaned-up-the-freed-pipefs-de.patch
  (git-fixes CVE-2023-52803 bsc#1225008).
- Update
  patches.suse/SUNRPC-fix-a-memleak-in-gss_import_v2_context.patch
  (git-fixes bsc#1223858 CVE-2023-52653 bsc#1223712).
- Update
  patches.suse/ceph-blocklist-the-kclient-when-receiving-corrupted-snap-trace.patch
  (jsc#SES-1880 CVE-2023-52732 bsc#1225222).
- Update
  patches.suse/crypto-s390-aes-Fix-buffer-overread-in-CTR-mode.patch
  (git-fixes CVE-2023-52669 bsc#1224637).
- Update
  patches.suse/drm-amd-display-fix-a-NULL-pointer-dereference-in-am.patch
  (git-fixes CVE-2023-52773 bsc#1225041).
- Update
  patches.suse/drm-amd-pm-fix-a-double-free-in-si_dpm_init.patch
  (git-fixes CVE-2023-52691 bsc#1224607).
- Update
  patches.suse/drm-amdgpu-vkms-fix-a-possible-null-pointer-derefere.patch
  (git-fixes CVE-2023-52815 bsc#1225568).
- Update
  patches.suse/drm-amdkfd-Confirm-list-is-non-empty-before-utilizin.patch
  (git-fixes CVE-2023-52678 bsc#1224617).
- Update
  patches.suse/drm-bridge-it66121-Fix-invalid-connector-dereference.patch
  (git-fixes CVE-2023-52861 bsc#1224941).
- Update
  patches.suse/drm-bridge-tpd12s015-Drop-buggy-__exit-annotation-fo.patch
  (git-fixes CVE-2023-52694 bsc#1224598).
- Update
  patches.suse/drm-tegra-dsi-Add-missing-check-for-of_find_device_b.patch
  (git-fixes CVE-2023-52650 bsc#1223770).
- Update
  patches.suse/drm-tegra-rgb-Fix-missing-clk_put-in-the-error-handl.patch
  (git-fixes CVE-2023-52661 bsc#1224445).
- Update
  patches.suse/drm-vmwgfx-fix-a-memleak-in-vmw_gmrid_man_get_node.patch
  (git-fixes CVE-2023-52662 bsc#1224449).
- Update
  patches.suse/fbdev-Fix-invalid-page-access-after-closing-deferred.patch
  (bsc#1207284 CVE-2023-52731 bsc#1224929).
- Update
  patches.suse/iio-core-fix-memleak-in-iio_device_register_sysfs.patch
  (git-fixes CVE-2023-52643 bsc#1222960).
- Update
  patches.suse/media-rc-bpf-attach-detach-requires-write-permission.patch
  (git-fixes CVE-2023-52642 bsc#1223031).
- Update
  patches.suse/nilfs2-fix-underflow-in-second-superblock-position-c.patch
  (git-fixes CVE-2023-52705 bsc#1225480).
- Update
  patches.suse/of-Fix-double-free-in-of_parse_phandle_with_args_map.patch
  (git-fixes CVE-2023-52679 bsc#1224508).
- 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_.patch
  (git-fixes CVE-2023-52685 bsc#1224728).
- Update
  patches.suse/scsi-hisi_sas-Set-debugfs_dir-pointer-to-NULL-after-removing-debugfs.patch
  (git-fixes CVE-2023-52808 bsc#1225555).
- Update
  patches.suse/scsi-ibmvfc-Remove-BUG_ON-in-the-case-of-an-empty-ev.patch
  (bsc#1209834 ltc#202097 CVE-2023-52811 bsc#1225559).
- 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/sysv-don-t-call-sb_bread-with-pointers_lock-held.patch
  (git-fixes CVE-2023-52699 bsc#1224659).
- Update
  patches.suse/wifi-ath11k-fix-gtk-offload-status-event-locking.patch
  (git-fixes CVE-2023-52777 bsc#1224992).
- Update
  patches.suse/wifi-b43-Stop-wake-correct-queue-in-DMA-Tx-path-when.patch
  (git-fixes CVE-2023-52644 bsc#1222961).
- Update
  patches.suse/x86-mm-Ensure-input-to-pfn_to_kaddr-is-treated-as-a-64-bit-type.patch
  (jsc#PED-7167 git-fixes CVE-2023-52659 bsc#1224442).
- commit c90a371

- Update
  patches.suse/1622-drm-gma500-Fix-WARN_ON-lock-magic-lock-error.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 jsc#PED-2849
  CVE-2022-48633 bsc#1223489).
- Update
  patches.suse/powerpc-pseries-Fix-potential-memleak-in-papr_get_at.patch
  (bsc#1200465 ltc#197256 jsc#SLE-18130 git-fixes CVE-2022-48669
  bsc#1223756).
- Update
  patches.suse/wifi-mt76-mt7921e-fix-crash-in-chip-reset-fail.patch
  (bsc#1209980 CVE-2022-48705 bsc#1223895).
- commit 5061b21

- Update
  patches.suse/1321-drm-msm-devfreq-Fix-OPP-refcnt-leak.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225
  CVE-2021-47532 bsc#1225444).
- Update
  patches.suse/1322-drm-msm-Fix-mmap-to-include-VM_IO-and-VM_DONTDUMP.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225
  CVE-2021-47531 bsc#1225443).
- Update
  patches.suse/1323-drm-msm-Fix-wait_fence-submitqueue-leak.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225
  CVE-2021-47530 bsc#1225442).
- Update
  patches.suse/blk-mq-cancel-blk-mq-dispatch-work-in-both-blk_clean.patch
  (jsc#PED-1183 CVE-2021-47552 bsc#1225513).
- Update
  patches.suse/btrfs-free-exchange-changeset-on-failures.patch
  (git-fixes CVE-2021-47508 bsc#1225408).
- Update
  patches.suse/io_uring-ensure-task_work-gets-run-as-part-of-cancel.patch
  (bsc#1205205 CVE-2021-47504 bsc#1225382).
- Update
  patches.suse/io_uring-fail-cancellation-for-EXITING-tasks.patch
  (bsc#1205205 CVE-2021-47569 bsc#1225515).
- Update
  patches.suse/net-sched-fq_pie-prevent-dismantle-issue.patch
  (bsc#1207361 CVE-2021-47512 bsc#1225424).
- Update
  patches.suse/net-sched-sch_ets-don-t-peek-at-classes-beyond-nband.patch
  (bsc#1207361 CVE-2021-47557 bsc#1225468).
- Update
  patches.suse/net-vlan-fix-underflow-for-the-real_dev-refcnt.patch
  (git-fixes CVE-2021-47555 bsc#1225467).
- commit 89b5f8b

- Update
  patches.suse/ALSA-hda-Do-not-unset-preset-when-cleaning-up-codec.patch
  (git-fixes CVE-2023-52736 bsc#1225486).
- Update
  patches.suse/ALSA-hda-Fix-possible-null-ptr-deref-when-assigning-.patch
  (git-fixes CVE-2023-52806 bsc#1225554).
- Update
  patches.suse/Bluetooth-btusb-Add-date-evt_skb-is-NULL-check.patch
  (git-fixes CVE-2023-52833 bsc#1225595).
- Update
  patches.suse/Fix-page-corruption-caused-by-racy-check-in-__free_pages.patch
  (bsc#1208149 CVE-2023-52739 bsc#1225118).
- Update
  patches.suse/IB-IPoIB-Fix-legacy-IPoIB-due-to-wrong-number-of-que.patch
  (git-fixes CVE-2023-52745 bsc#1225032).
- Update
  patches.suse/IB-hfi1-Restore-allocated-resources-on-failed-copyou.patch
  (git-fixes CVE-2023-52747 bsc#1224931).
- Update
  patches.suse/Input-synaptics-rmi4-fix-use-after-free-in-rmi_unreg.patch
  (git-fixes CVE-2023-52840 bsc#1224928).
- Update
  patches.suse/RDMA-irdma-Fix-potential-NULL-ptr-dereference.patch
  (git-fixes CVE-2023-52744 bsc#1225121).
- Update
  patches.suse/atl1c-Work-around-the-DMA-RX-overflow-issue.patch
  (git-fixes CVE-2023-52834 bsc#1225599).
- Update
  patches.suse/can-dev-can_put_echo_skb-don-t-crash-kernel-if-can_p.patch
  (git-fixes CVE-2023-52878 bsc#1225000).
- Update
  patches.suse/cifs-Fix-use-after-free-in-rdata-read_into_pages-.patch
  (git-fixes CVE-2023-52741 bsc#1225479).
- Update
  patches.suse/clk-mediatek-clk-mt2701-Add-check-for-mtk_alloc_clk_.patch
  (git-fixes CVE-2023-52875 bsc#1225096).
- Update
  patches.suse/clk-mediatek-clk-mt6765-Add-check-for-mtk_alloc_clk_.patch
  (git-fixes CVE-2023-52870 bsc#1224937).
- Update
  patches.suse/clk-mediatek-clk-mt6779-Add-check-for-mtk_alloc_clk_.patch
  (git-fixes CVE-2023-52873 bsc#1225589).
- Update
  patches.suse/clk-mediatek-clk-mt6797-Add-check-for-mtk_alloc_clk_.patch
  (git-fixes CVE-2023-52865 bsc#1225086).
- Update
  patches.suse/clk-mediatek-clk-mt7629-Add-check-for-mtk_alloc_clk_.patch
  (git-fixes CVE-2023-52858 bsc#1225566).
- Update
  patches.suse/clk-mediatek-clk-mt7629-eth-Add-check-for-mtk_alloc_.patch
  (git-fixes CVE-2023-52876 bsc#1225036).
- Update
  patches.suse/drm-amd-Fix-UBSAN-array-index-out-of-bounds-for-Pola.patch
  (git-fixes CVE-2023-52819 bsc#1225532).
- Update
  patches.suse/drm-amd-Fix-UBSAN-array-index-out-of-bounds-for-SMU7.patch
  (git-fixes CVE-2023-52818 bsc#1225530).
- Update
  patches.suse/drm-amd-display-Avoid-NULL-dereference-of-timing-gen.patch
  (git-fixes CVE-2023-52753 bsc#1225478).
- Update
  patches.suse/drm-amdgpu-Fix-a-null-pointer-access-when-the-smc_rr.patch
  (git-fixes CVE-2023-52817 bsc#1225569).
- Update
  patches.suse/drm-amdgpu-Fix-potential-null-pointer-derefernce.patch
  (git-fixes CVE-2023-52814 bsc#1225565).
- Update
  patches.suse/drm-amdgpu-fence-Fix-oops-due-to-non-matching-drm_sc.patch
  (git-fixes CVE-2023-52738 bsc#1225005).
- Update
  patches.suse/drm-amdkfd-Fix-a-race-condition-of-vram-buffer-unref.patch
  (git-fixes CVE-2023-52825 bsc#1225076).
- Update
  patches.suse/drm-amdkfd-Fix-shift-out-of-bounds-issue.patch
  (git-fixes CVE-2023-52816 bsc#1225529).
- Update
  patches.suse/drm-bridge-lt8912b-Fix-crash-on-bridge-detach.patch
  (git-fixes CVE-2023-52856 bsc#1224932).
- Update
  patches.suse/drm-panel-fix-a-possible-null-pointer-dereference.patch
  (git-fixes CVE-2023-52821 bsc#1225022).
- Update
  patches.suse/drm-panel-panel-tpo-tpg110-fix-a-possible-null-point.patch
  (git-fixes CVE-2023-52826 bsc#1225077).
- Update patches.suse/drm-radeon-possible-buffer-overflow.patch
  (git-fixes CVE-2023-52867 bsc#1225009).
- Update
  patches.suse/fbdev-imsttfb-fix-a-resource-leak-in-probe.patch
  (git-fixes CVE-2023-52838 bsc#1225031).
- Update
  patches.suse/fs-jfs-Add-check-for-negative-db_l2nbperpage.patch
  (git-fixes CVE-2023-52810 bsc#1225557).
- Update
  patches.suse/fs-jfs-Add-validity-check-for-db_maxag-and-db_agpref.patch
  (git-fixes CVE-2023-52804 bsc#1225550).
- Update patches.suse/gfs2-ignore-negated-quota-changes.patch
  (git-fixes CVE-2023-52759 bsc#1225560).
- Update
  patches.suse/hid-cp2112-Fix-duplicate-workqueue-initialization.patch
  (git-fixes CVE-2023-52853 bsc#1224988).
- Update
  patches.suse/i2c-core-Run-atomic-i2c-xfer-when-preemptible.patch
  (git-fixes CVE-2023-52791 bsc#1225108).
- Update
  patches.suse/i3c-master-mipi-i3c-hci-Fix-a-kernel-panic-for-acces.patch
  (git-fixes CVE-2023-52763 bsc#1225570).
- Update
  patches.suse/i915-perf-Fix-NULL-deref-bugs-with-drm_dbg-calls.patch
  (git-fixes CVE-2023-52788 bsc#1225106).
- Update
  patches.suse/ice-Do-not-use-WQ_MEM_RECLAIM-flag-for-workqueue.patch
  (git-fixes CVE-2023-52743 bsc#1225003).
- Update
  patches.suse/jfs-fix-array-index-out-of-bounds-in-dbFindLeaf.patch
  (git-fixes CVE-2023-52799 bsc#1225472).
- Update
  patches.suse/jfs-fix-array-index-out-of-bounds-in-diAlloc.patch
  (git-fixes CVE-2023-52805 bsc#1225553).
- Update
  patches.suse/media-bttv-fix-use-after-free-error-due-to-btv-timeo.patch
  (git-fixes CVE-2023-52847 bsc#1225588).
- Update
  patches.suse/media-gspca-cpia1-shift-out-of-bounds-in-set_flicker.patch
  (git-fixes CVE-2023-52764 bsc#1225571).
- Update
  patches.suse/media-imon-fix-access-to-invalid-resource-for-the-se.patch
  (git-fixes CVE-2023-52754 bsc#1225490).
- Update
  patches.suse/media-vidtv-mux-Add-check-and-kfree-for-kstrdup.patch
  (git-fixes CVE-2023-52841 bsc#1225592).
- Update patches.suse/media-vidtv-psi-Add-check-for-kstrdup.patch
  (git-fixes CVE-2023-52844 bsc#1225590).
- Update
  patches.suse/mmc-mmc_spi-fix-error-handling-in-mmc_spi_probe.patch
  (git-fixes CVE-2023-52708 bsc#1225483).
- Update
  patches.suse/mmc-sdio-fix-possible-resource-leaks-in-some-error-p.patch
  (git-fixes CVE-2023-52730 bsc#1224956).
- Update
  patches.suse/net-USB-Fix-wrong-direction-WARNING-in-plusb.c.patch
  (git-fixes CVE-2023-52742 bsc#1225482).
- Update
  patches.suse/net-openvswitch-fix-possible-memory-leak-in-ovs_mete.patch
  (git-fixes CVE-2023-52702 bsc#1224945).
- Update
  patches.suse/net-usb-kalmia-Don-t-pass-act_len-in-usb_bulk_msg-er.patch
  (git-fixes CVE-2023-52703 bsc#1225549).
- Update
  patches.suse/padata-Fix-refcnt-handling-in-padata_free_shell.patch
  (git-fixes CVE-2023-52854 bsc#1225584).
- Update
  patches.suse/platform-x86-wmi-Fix-opening-of-char-device.patch
  (git-fixes CVE-2023-52864 bsc#1225132).
- Update
  patches.suse/powerpc-64s-interrupt-Fix-interrupt-exit-race-with-s.patch
  (bsc#1194869 CVE-2023-52740 bsc#1225471).
- 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-to-scom_deb.patch
  (bsc#1194869 CVE-2023-52690 bsc#1224611).
- Update patches.suse/pwm-Fix-double-shift-bug.patch (git-fixes
  CVE-2023-52756 bsc#1225461).
- Update
  patches.suse/s390-dasd-protect-device-queue-against-concurrent-access.patch
  (git-fixes bsc#1217515 CVE-2023-52774 bsc#1225572).
- Update
  patches.suse/s390-decompressor-specify-__decompress-buf-len-to-avoid-overflow.patch
  (git-fixes bsc#1213863 CVE-2023-52733 bsc#1225488).
- Update
  patches.suse/sched-psi-Fix-use-after-free-in-ep_remove_wait_queue.patch
  (bsc#1209799 CVE-2023-52707 bsc#1225109).
- Update
  patches.suse/soc-qcom-llcc-Handle-a-second-device-without-data-co.patch
  (git-fixes CVE-2023-52871 bsc#1225534).
- Update
  patches.suse/thermal-core-prevent-potential-string-overflow.patch
  (git-fixes CVE-2023-52868 bsc#1225044).
- Update
  patches.suse/tty-n_gsm-fix-race-condition-in-status-line-change-o.patch
  (git-fixes CVE-2023-52872 bsc#1225591).
- Update
  patches.suse/tty-n_gsm-require-CAP_NET_ADMIN-to-attach-N_GSM0710-.patch
  (bsc#1222619 CVE-2023-52880).
- Update
  patches.suse/tty-vcc-Add-check-for-kstrdup-in-vcc_probe.patch
  (git-fixes CVE-2023-52789 bsc#1225180).
- Update
  patches.suse/usb-config-fix-iteration-issue-in-usb_get_bos_descri.patch
  (git-fixes CVE-2023-52781 bsc#1225092).
- Update
  patches.suse/usb-dwc2-fix-possible-NULL-pointer-dereference-cause.patch
  (git-fixes CVE-2023-52855 bsc#1225583).
- Update
  patches.suse/usb-typec-tcpm-Fix-NULL-pointer-dereference-in-tcpm_.patch
  (git-fixes CVE-2023-52877 bsc#1224944).
- Update
  patches.suse/wifi-ath11k-fix-dfs-radar-event-locking.patch
  (git-fixes CVE-2023-52798 bsc#1224947).
- Update
  patches.suse/wifi-mac80211-don-t-return-unset-power-in-ieee80211_.patch
  (git-fixes CVE-2023-52832 bsc#1225577).
- commit c6aceca

- Update
  patches.suse/drm-radeon-fix-a-possible-null-pointer-dereference.patch
  (git-fixes CVE-2022-48710 bsc#1225230).
- Update
  patches.suse/ice-switch-fix-potential-memleak-in-ice_add_adv_reci.patch
  (git-fixes CVE-2022-48709 bsc#1225095).
- Update
  patches.suse/pinctrl-single-fix-potential-NULL-dereference.patch
  (git-fixes CVE-2022-48708 bsc#1224942).
- commit 41f6d79

- Update
  patches.suse/ALSA-pcm-oss-Fix-negative-period-buffer-sizes.patch
  (git-fixes CVE-2021-47511 bsc#1225411).
- Update
  patches.suse/ALSA-pcm-oss-Limit-the-period-size-to-16MB.patch
  (git-fixes CVE-2021-47509 bsc#1225409).
- Update
  patches.suse/ASoC-SOF-Fix-DSP-oops-stack-dump-output-contents.patch
  (git-fixes stable-5.14.10 CVE-2021-47381 bsc#1225206).
- Update
  patches.suse/ASoC-codecs-wcd934x-handle-channel-mappping-list-cor.patch
  (git-fixes CVE-2021-47502 bsc#1225369).
- Update
  patches.suse/HID-amd_sfh-Fix-potential-NULL-pointer-dereference.patch
  (stable-5.14.10 CVE-2021-47380 bsc#1225205).
- Update
  patches.suse/HID-betop-fix-slab-out-of-bounds-Write-in-betop_prob.patch
  (stable-5.14.10 CVE-2021-47404 bsc#1225303).
- Update
  patches.suse/HID-bigbenff-prevent-null-pointer-dereference.patch
  (git-fixes CVE-2021-47522 bsc#1225437).
- Update
  patches.suse/HID-usbhid-free-raw_report-buffers-in-usbhid_stop.patch
  (stable-5.14.10 CVE-2021-47405 bsc#1225238).
- Update
  patches.suse/IB-hfi1-Fix-leak-of-rcvhdrtail_dummy_kvaddr.patch
  (jsc#SLE-19242 CVE-2021-47523 bsc#1225438).
- Update
  patches.suse/IB-qib-Protect-from-buffer-overflow-in-struct-qib_us.patch
  (stable-5.14.16 CVE-2021-47485 bsc#1224904).
- Update
  patches.suse/KVM-PPC-Book3S-HV-Fix-stack-handling-in-idle_kvm_sta.patch
  (stable-5.14.15 bko#206669 bsc#1174585 bsc#1192107
  CVE-2021-43056 CVE-2021-47465 bsc#1225341).
- Update
  patches.suse/KVM-SVM-fix-missing-sev_decommission-in-sev_receive_.patch
  (stable-5.14.10 CVE-2021-47389 bsc#1225126).
- Update
  patches.suse/KVM-arm64-Fix-host-stage-2-PGD-refcount.patch
  (stable-5.14.15 CVE-2021-47450 bsc#1225258).
- Update
  patches.suse/KVM-x86-Fix-stack-out-of-bounds-memory-access-from-i.patch
  (stable-5.14.10 CVE-2021-47390 bsc#1225125).
- Update
  patches.suse/KVM-x86-Handle-SRCU-initialization-failure-during-pa.patch
  (stable-5.14.10 CVE-2021-47407 bsc#1225306).
- Update
  patches.suse/NFC-digital-fix-possible-memory-leak-in-digital_in_s.patch
  (stable-5.14.14 CVE-2021-47442 bsc#1225263).
- Update
  patches.suse/NFC-digital-fix-possible-memory-leak-in-digital_tg_l.patch
  (stable-5.14.14 CVE-2021-47443 bsc#1225262).
- Update
  patches.suse/RDMA-cma-Ensure-rdma_addr_cancel-happens-before-issu.patch
  (stable-5.14.10 CVE-2021-47391 bsc#1225318).
- Update
  patches.suse/RDMA-cma-Fix-listener-leak-in-rdma_cma_listen_on_all.patch
  (stable-5.14.10 CVE-2021-47392 bsc#1225320).
- Update patches.suse/RDMA-hfi1-Fix-kernel-pointer-leak.patch
  (stable-5.14.10 CVE-2021-47398 bsc#1225131).
- Update
  patches.suse/RDMA-mlx5-Initialize-the-ODP-xarray-when-creating-an.patch
  (stable-5.14.16 CVE-2021-47481 bsc#1224910).
- Update
  patches.suse/afs-Fix-corruption-in-reads-at-fpos-2G-4G-from-an-Op.patch
  (stable-5.14.9 CVE-2021-47366 bsc#1225160).
- Update
  patches.suse/aio-fix-use-after-free-due-to-missing-POLLFREE-handl.patch
  (CVE-2021-39698 bsc#1196956 CVE-2021-47505 bsc#1225400).
- Update
  patches.suse/audit-fix-possible-null-pointer-dereference-in-audit.patch
  (stable-5.14.15 CVE-2021-47464 bsc#1225393).
- Update patches.suse/binder-make-sure-fd-closes-complete.patch
  (stable-5.14.9 CVE-2021-47360 bsc#1225122).
- Update
  patches.suse/blk-cgroup-fix-UAF-by-grabbing-blkcg-lock-before-des.patch
  (stable-5.14.9 CVE-2021-47379 bsc#1225203).
- Update
  patches.suse/blktrace-Fix-uaf-in-blk_trace-access-after-removing-.patch
  (stable-5.14.9 CVE-2021-47375 bsc#1225193).
- Update
  patches.suse/block-don-t-call-rq_qos_ops-done_bio-if-the-bio-isn-.patch
  (stable-5.14.11 CVE-2021-47412 bsc#1225332).
- Update
  patches.suse/bpf-Add-oversize-check-before-call-kvcalloc.patch
  (stable-5.14.9 CVE-2021-47376 bsc#1225195).
- Update
  patches.suse/bpf-s390-Fix-potential-memory-leak-about-jit_data.patch
  (stable-5.14.12 CVE-2021-47426 bsc#1225370).
- Update
  patches.suse/btrfs-fix-abort-logic-in-btrfs_replace_file_extents.patch
  (stable-5.14.14 CVE-2021-47433 bsc#1225392).
- Update
  patches.suse/btrfs-fix-re-dirty-process-of-tree-log-nodes.patch
  (bsc#1197915 CVE-2021-47510 bsc#1225410).
- Update
  patches.suse/can-isotp-isotp_sendmsg-add-result-check-for-wait_ev.patch
  (stable-5.14.15 CVE-2021-47457 bsc#1225235).
- Update
  patches.suse/can-j1939-j1939_netdev_start-fix-UAF-for-rx_kref-of-.patch
  (stable-5.14.15 CVE-2021-47459 bsc#1225253).
- Update
  patches.suse/can-pch_can-pch_can_rx_normal-fix-use-after-free.patch
  (git-fixes CVE-2021-47520 bsc#1225431).
- Update patches.suse/can-peak_pci-peak_pci_remove-fix-UAF.patch
  (stable-5.14.15 CVE-2021-47456 bsc#1225256).
- Update
  patches.suse/can-sja1000-fix-use-after-free-in-ems_pcmcia_add_car.patch
  (git-fixes CVE-2021-47521 bsc#1225435).
- Update
  patches.suse/cfg80211-fix-management-registrations-locking.patch
  (git-fixes stable-5.14.16 CVE-2021-47494 bsc#1225450).
- Update
  patches.suse/cgroup-Fix-memory-leak-caused-by-missing-cgroup_bpf_.patch
  (stable-5.14.16 CVE-2021-47488 bsc#1224902).
- Update patches.suse/cifs-Fix-soft-lockup-during-fsstress.patch
  (stable-5.14.9 CVE-2021-47359 bsc#1225145).
- Update
  patches.suse/comedi-Fix-memory-leak-in-compat_insnlist.patch
  (stable-5.14.9 CVE-2021-47364 bsc#1225158).
- Update patches.suse/comedi-dt9812-fix-DMA-buffers-on-stack.patch
  (git-fixes stable-5.14.18 CVE-2021-47477 bsc#1224912).
- Update
  patches.suse/comedi-ni_usb6501-fix-NULL-deref-in-command-paths.patch
  (git-fixes stable-5.14.18 CVE-2021-47476 bsc#1224913).
- Update
  patches.suse/comedi-vmk80xx-fix-bulk-buffer-overflow.patch
  (git-fixes stable-5.14.18 CVE-2021-47474 bsc#1224915).
- Update
  patches.suse/comedi-vmk80xx-fix-transfer-buffer-overflows.patch
  (git-fixes stable-5.14.18 CVE-2021-47475 bsc#1224914).
- Update
  patches.suse/cpufreq-schedutil-Use-kobject-release-method-to-free.patch
  (stable-5.14.10 CVE-2021-47387 bsc#1225316).
- Update
  patches.suse/devlink-fix-netns-refcount-leak-in-devlink_nl_cmd_re.patch
  (git-fixes CVE-2021-47514 bsc#1225425).
- Update
  patches.suse/dm-fix-mempool-NULL-pointer-race-when-completing-IO.patch
  (stable-5.14.14 CVE-2021-47435 bsc#1225247).
- Update
  patches.suse/dm-rq-don-t-queue-request-to-blk-mq-during-DM-suspen.patch
  (stable-5.14.14 CVE-2021-47498 bsc#1225357).
- Update
  patches.suse/dma-debug-prevent-an-error-message-from-causing-runt.patch
  (stable-5.14.9 CVE-2021-47374 bsc#1225191).
- Update patches.suse/drm-amd-amdgpu-fix-potential-memleak.patch
  (git-fixes CVE-2021-47550 bsc#1225379).
- Update
  patches.suse/drm-amd-amdkfd-Fix-kernel-panic-when-reset-failed-an.patch
  (git-fixes CVE-2021-47551 bsc#1225510).
- Update
  patches.suse/drm-amd-pm-Update-intermediate-power-state-for-SI.patch
  (stable-5.14.9 CVE-2021-47362 bsc#1225153).
- Update patches.suse/drm-amdgpu-fix-gart.bo-pin_count-leak.patch
  (stable-5.14.13 CVE-2021-47431 bsc#1225390).
- Update
  patches.suse/drm-amdgpu-handle-the-case-of-pci_channel_io_frozen-.patch
  (git-fixes stable-5.14.12 CVE-2021-47421 bsc#1225353).
- Update
  patches.suse/drm-amdkfd-fix-a-potential-ttm-sg-memory-leak.patch
  (git-fixes stable-5.14.12 CVE-2021-47420 bsc#1225339).
- Update
  patches.suse/drm-amdkfd-fix-svm_migrate_fini-warning.patch
  (stable-5.14.11 CVE-2021-47410 bsc#1225331).
- Update
  patches.suse/drm-edid-In-connector_bad_edid-cap-num_of_ext-by-num.patch
  (git-fixes stable-5.14.14 CVE-2021-47444 bsc#1225243).
- Update
  patches.suse/drm-msm-Fix-null-pointer-dereference-on-pointer-edp.patch
  (git-fixes stable-5.14.14 CVE-2021-47445 bsc#1225261).
- Update
  patches.suse/drm-msm-a3xx-fix-error-handling-in-a3xx_gpu_init.patch
  (git-fixes stable-5.14.14 CVE-2021-47447 bsc#1225260).
- Update
  patches.suse/drm-msm-a4xx-fix-error-handling-in-a4xx_gpu_init.patch
  (git-fixes stable-5.14.14 CVE-2021-47446 bsc#1225240).
- Update
  patches.suse/drm-msm-a6xx-Allocate-enough-space-for-GMU-registers.patch
  (git-fixes CVE-2021-47535 bsc#1225446).
- Update
  patches.suse/drm-mxsfb-Fix-NULL-pointer-dereference-crash-on-unlo.patch
  (stable-5.14.15 CVE-2021-47471 bsc#1225187).
- Update
  patches.suse/drm-nouveau-debugfs-fix-file-release-memory-leak.patch
  (git-fixes stable-5.14.12 CVE-2021-47423 bsc#1225366).
- Update
  patches.suse/drm-nouveau-kms-nv50-fix-file-release-memory-leak.patch
  (git-fixes stable-5.14.12 CVE-2021-47422 bsc#1225233).
- Update
  patches.suse/drm-ttm-fix-memleak-in-ttm_transfered_destroy.patch
  (stable-5.14.16 CVE-2021-47490 bsc#1225436).
- Update
  patches.suse/drm-vc4-kms-Clear-the-HVS-FIFO-commit-pointer-once-d.patch
  (git-fixes CVE-2021-47533 bsc#1225445).
- Update
  patches.suse/enetc-Fix-illegal-access-when-reading-affinity_hint.patch
  (stable-5.14.9 CVE-2021-47368 bsc#1225161).
- Update
  patches.suse/ethtool-ioctl-fix-potential-NULL-deref-in-ethtool_se.patch
  (jsc#SLE-19253 CVE-2021-47556 bsc#1225383).
- Update
  patches.suse/ext4-add-error-checking-to-ext4_ext_replay_set_ibloc.patch
  (stable-5.14.10 CVE-2021-47406 bsc#1225304).
- Update
  patches.suse/hwmon-mlxreg-fan-Return-non-zero-value-when-fan-curr.patch
  (git-fixes stable-5.14.10 CVE-2021-47393 bsc#1225321).
- Update
  patches.suse/hwmon-w83791d-Fix-NULL-pointer-dereference-by-removi.patch
  (stable-5.14.10 CVE-2021-47386 bsc#1225268).
- Update
  patches.suse/hwmon-w83792d-Fix-NULL-pointer-dereference-by-removi.patch
  (stable-5.14.10 CVE-2021-47385 bsc#1225210).
- Update
  patches.suse/hwmon-w83793-Fix-NULL-pointer-dereference-by-removin.patch
  (stable-5.14.10 CVE-2021-47384 bsc#1225209).
- Update
  patches.suse/i2c-acpi-fix-resource-leak-in-reconfiguration-device.patch
  (git-fixes stable-5.14.12 CVE-2021-47425 bsc#1225223).
- Update
  patches.suse/i40e-Fix-NULL-pointer-dereference-in-i40e_dbg_dump_d.patch
  (jsc#SLE-18378 CVE-2021-47501 bsc#1225361).
- Update
  patches.suse/i40e-Fix-freeing-of-uninitialized-misc-IRQ-vector.patch
  (stable-5.14.12 CVE-2021-47424 bsc#1225367).
- Update
  patches.suse/ice-Avoid-crash-from-unnecessary-IDA-free.patch
  (stable-5.14.15 CVE-2021-47453 bsc#1225239).
- Update patches.suse/ice-avoid-bpf_prog-refcount-underflow.patch
  (jsc#SLE-18375 CVE-2021-47563 bsc#1225500).
- Update
  patches.suse/ice-fix-locking-for-Tx-timestamp-tracking-flush.patch
  (stable-5.14.14 CVE-2021-47449 bsc#1225259).
- Update patches.suse/ice-fix-vsi-txq_map-sizing.patch
  (jsc#SLE-18375 CVE-2021-47562 bsc#1225499).
- Update
  patches.suse/iio-accel-kxcjk-1013-Fix-possible-memory-leak-in-pro.patch
  (git-fixes CVE-2021-47499 bsc#1225358).
- Update
  patches.suse/iio-adis16475-fix-deadlock-on-frequency-set.patch
  (git-fixes stable-5.14.14 CVE-2021-47437 bsc#1225245).
- Update
  patches.suse/iio-mma8452-Fix-trigger-reference-couting.patch
  (git-fixes CVE-2021-47500 bsc#1225360).
- Update
  patches.suse/ipack-ipoctal-fix-module-reference-leak.patch
  (stable-5.14.10 CVE-2021-47403 bsc#1225241).
- Update
  patches.suse/ipack-ipoctal-fix-stack-information-leak.patch
  (stable-5.14.10 CVE-2021-47401 bsc#1225242).
- Update
  patches.suse/irqchip-gic-v3-its-Fix-potential-VPE-leak-on-error.patch
  (stable-5.14.9 CVE-2021-47373 bsc#1225190).
- Update
  patches.suse/isdn-mISDN-Fix-sleeping-function-called-from-invalid.patch
  (stable-5.14.15 CVE-2021-47468 bsc#1225346).
- Update
  patches.suse/isofs-Fix-out-of-bound-access-for-corrupted-isofs-im.patch
  (stable-5.14.18 CVE-2021-47478 bsc#1225198).
- Update
  patches.suse/iwlwifi-Fix-memory-leaks-in-error-handling-path.patch
  (git-fixes CVE-2021-47529 bsc#1225373).
- Update
  patches.suse/iwlwifi-mvm-Fix-possible-NULL-dereference.patch
  (git-fixes stable-5.14.12 CVE-2021-47415 bsc#1225335).
- Update
  patches.suse/ixgbe-Fix-NULL-pointer-dereference-in-ixgbe_xdp_setu.patch
  (stable-5.14.10 CVE-2021-47399 bsc#1225328).
- Update
  patches.suse/kunit-fix-reference-count-leak-in-kfree_at_end.patch
  (stable-5.14.15 CVE-2021-47467 bsc#1225344).
- Update patches.suse/libbpf-Fix-memory-leak-in-strset.patch
  (git-fixes stable-5.14.12 CVE-2021-47417 bsc#1225227).
- Update
  patches.suse/mac80211-fix-use-after-free-in-CCMP-GCMP-RX.patch
  (git-fixes stable-5.14.10 CVE-2021-47388 bsc#1225214).
- Update
  patches.suse/mac80211-hwsim-fix-late-beacon-hrtimer-handling.patch
  (git-fixes stable-5.14.10 CVE-2021-47396 bsc#1225327).
- Update
  patches.suse/mac80211-limit-injected-vht-mcs-nss-in-ieee80211_par.patch
  (git-fixes stable-5.14.10 CVE-2021-47395 bsc#1225326).
- Update
  patches.suse/mcb-fix-error-handling-in-mcb_alloc_bus.patch
  (stable-5.14.9 CVE-2021-47361 bsc#1225151).
- Update
  patches.suse/mlxsw-spectrum-Protect-driver-from-buggy-firmware.patch
  (git-fixes CVE-2021-47560 bsc#1225495).
- Update
  patches.suse/mlxsw-thermal-Fix-out-of-bounds-memory-accesses.patch
  (stable-5.14.14 CVE-2021-47441 bsc#1225224).
- Update
  patches.suse/mm-mempolicy-do-not-allow-illegal-MPOL_F_NUMA_BALANC.patch
  (stable-5.14.15 CVE-2021-47462 bsc#1225250).
- Update
  patches.suse/mm-secretmem-fix-NULL-page-mapping-dereference-in-pa.patch
  (stable-5.14.15 CVE-2021-47463 bsc#1225127).
- Update
  patches.suse/mm-slub-fix-potential-memoryleak-in-kmem_cache_open.patch
  (stable-5.14.15 CVE-2021-47466 bsc#1225342).
- Update
  patches.suse/mm-slub-fix-potential-use-after-free-in-slab_debugfs.patch
  (stable-5.14.15 CVE-2021-47470 bsc#1225186).
- Update
  patches.suse/mptcp-ensure-tx-skbs-always-have-the-MPTCP-ext.patch
  (stable-5.14.9 CVE-2021-47370 bsc#1225183).
- Update patches.suse/mptcp-fix-possible-stall-on-recvmsg.patch
  (stable-5.14.14 CVE-2021-47448 bsc#1225129).
- Update
  patches.suse/mt76-mt7915-fix-NULL-pointer-dereference-in-mt7915_g.patch
  (git-fixes CVE-2021-47540 bsc#1225386).
- Update patches.suse/net-batman-adv-fix-error-handling.patch
  (git-fixes stable-5.14.16 CVE-2021-47482 bsc#1224909).
- Update
  patches.suse/net-dsa-felix-Fix-memory-leak-in-felix_setup_mmio_fi.patch
  (git-fixes CVE-2021-47513 bsc#1225380).
- Update
  patches.suse/net-dsa-microchip-Added-the-condition-for-scheduling.patch
  (stable-5.14.14 CVE-2021-47439 bsc#1225246).
- Update
  patches.suse/net-encx24j600-check-error-in-devm_regmap_init_encx2.patch
  (stable-5.14.14 CVE-2021-47440 bsc#1225248).
- Update
  patches.suse/net-hns3-do-not-allow-call-hns3_nic_net_open-repeate.patch
  (stable-5.14.10 CVE-2021-47400 bsc#1225329).
- Update patches.suse/net-macb-fix-use-after-free-on-rmmod.patch
  (stable-5.14.9 CVE-2021-47372 bsc#1225184).
- Update
  patches.suse/net-marvell-prestera-fix-double-free-issue-on-err-pa.patch
  (git-fixes CVE-2021-47564 bsc#1225501).
- Update
  patches.suse/net-mdiobus-Fix-memory-leak-in-__mdiobus_register.patch
  (stable-5.14.15 CVE-2021-47472 bsc#1225189).
- Update
  patches.suse/net-mlx4_en-Fix-an-use-after-free-bug-in-mlx4_en_try.patch
  (jsc#SLE-19256 CVE-2021-47541 bsc#1225453).
- Update
  patches.suse/net-mlx5e-Fix-memory-leak-in-mlx5_core_destroy_cq-er.patch
  (stable-5.14.14 CVE-2021-47438 bsc#1225229).
- Update
  patches.suse/net-qlogic-qlcnic-Fix-a-NULL-pointer-dereference-in-.patch
  (git-fixes CVE-2021-47542 bsc#1225455).
- Update
  patches.suse/net-sched-flower-protect-fl_walk-with-rcu.patch
  (stable-5.14.10 CVE-2021-47402 bsc#1225301).
- Update
  patches.suse/net-sched-sch_taprio-properly-cancel-timer-from-tapr.patch
  (stable-5.14.12 CVE-2021-47419 bsc#1225338).
- Update
  patches.suse/net-smc-Fix-NULL-pointer-dereferencing-in-smc_vlan_by_tcpsk
  (git-fixes CVE-2021-47559 bsc#1225396).
- Update
  patches.suse/net-smc-fix-wrong-list_del-in-smc_lgr_cleanup_early
  (git-fixes CVE-2021-47536 bsc#1225447).
- Update
  patches.suse/net-stmmac-Disable-Tx-queues-when-reconfiguring-the-.patch
  (jsc#SLE-19033 CVE-2021-47558 bsc#1225492).
- Update
  patches.suse/net-tls-Fix-flipped-sign-in-tls_err_abort-calls.patch
  (stable-5.14.16 CVE-2021-47496 bsc#1225354).
- Update
  patches.suse/net_sched-fix-NULL-deref-in-fifo_set_limit.patch
  (stable-5.14.12 CVE-2021-47418 bsc#1225337).
- Update
  patches.suse/netfilter-conntrack-serialize-hash-resizes-and-clean.patch
  (stable-5.14.10 CVE-2021-47408 bsc#1225236).
- Update
  patches.suse/netfilter-nf_tables-skip-netdev-events-generated-on-.patch
  (stable-5.14.15 CVE-2021-47452 bsc#1225257).
- Update
  patches.suse/netfilter-nf_tables-unlink-table-before-deleting-it.patch
  (stable-5.14.10 CVE-2021-47394 bsc#1225323).
- Update
  patches.suse/netfilter-xt_IDLETIMER-fix-panic-that-occurs-when-ti.patch
  (stable-5.14.15 CVE-2021-47451 bsc#1225237).
- Update
  patches.suse/nexthop-Fix-division-by-zero-while-replacing-a-resil.patch
  (stable-5.14.9 CVE-2021-47363 bsc#1225156).
- Update
  patches.suse/nexthop-Fix-memory-leaks-in-nexthop-notification-cha.patch
  (stable-5.14.9 CVE-2021-47371 bsc#1225167).
- Update
  patches.suse/nfc-fix-potential-NULL-pointer-deref-in-nfc_genl_dum.patch
  (git-fixes CVE-2021-47518 bsc#1225372).
- Update
  patches.suse/nfp-Fix-memory-leak-in-nfp_cpp_area_cache_add.patch
  (git-fixes CVE-2021-47516 bsc#1225427).
- Update patches.suse/nfsd-Fix-nsfd-startup-race-again.patch
  (git-fixes CVE-2021-47507 bsc#1225405).
- Update
  patches.suse/nfsd-fix-use-after-free-due-to-delegation-race.patch
  (git-fixes CVE-2021-47506 bsc#1225404).
- Update
  patches.suse/nvme-rdma-destroy-cm-id-before-destroy-qp-to-avoid-u.patch
  (bsc#1190569 stable-5.14.9 CVE-2021-47378 bsc#1225201).
- Update
  patches.suse/nvmem-Fix-shift-out-of-bound-UBSAN-with-byte-size-ce.patch
  (stable-5.14.14 CVE-2021-47497 bsc#1225355).
- Update
  patches.suse/ocfs2-fix-data-corruption-after-conversion-from-inli.patch
  (stable-5.14.15 CVE-2021-47460 bsc#1225251).
- Update
  patches.suse/ocfs2-fix-race-between-searching-chunks-and-release-.patch
  (stable-5.14.16 CVE-2021-47493 bsc#1225439).
- Update
  patches.suse/ocfs2-mount-fails-with-buffer-overflow-in-strlen.patch
  (stable-5.14.15 CVE-2021-47458 bsc#1225252).
- Update
  patches.suse/octeontx2-af-Fix-a-memleak-bug-in-rvu_mbox_init.patch
  (git-fixes CVE-2021-47537 bsc#1225375).
- Update
  patches.suse/octeontx2-af-Fix-possible-null-pointer-dereference.patch
  (stable-5.14.16 CVE-2021-47484 bsc#1224905).
- Update patches.suse/phy-mdio-fix-memory-leak.patch (git-fixes
  stable-5.14.12 CVE-2021-47416 bsc#1225336).
- Update
  patches.suse/powerpc-64s-Fix-unrecoverable-MCE-calling-async-hand.patch
  (stable-5.14.12 CVE-2021-47429 bsc#1225388).
- Update
  patches.suse/powerpc-64s-fix-program-check-interrupt-emergency-st.patch
  (stable-5.14.12 CVE-2021-47428 bsc#1225387).
- Update
  patches.suse/powerpc-smp-do-not-decrement-idle-task-preempt-count.patch
  (stable-5.14.15 CVE-2021-47454 bsc#1225255).
- Update
  patches.suse/ptp-Fix-possible-memory-leak-in-ptp_clock_register.patch
  (stable-5.14.15 CVE-2021-47455 bsc#1225254).
- Update
  patches.suse/regmap-Fix-possible-double-free-in-regcache_rbtree_e.patch
  (git-fixes stable-5.14.16 CVE-2021-47483 bsc#1224907).
- Update
  patches.suse/riscv-Flush-current-cpu-icache-before-other-cpus.patch
  (stable-5.14.12 CVE-2021-47414 bsc#1225334).
- Update
  patches.suse/riscv-bpf-Fix-potential-NULL-dereference.patch
  (stable-5.14.16 CVE-2021-47486 bsc#1224903).
- Update
  patches.suse/s390-qeth-fix-NULL-deref-in-qeth_clear_working_pool_.patch
  (stable-5.14.9 CVE-2021-47369 bsc#1225164).
- Update
  patches.suse/s390-qeth-fix-deadlock-during-failing-recovery.patch
  (stable-5.14.10 CVE-2021-47382 bsc#1225207).
- Update
  patches.suse/sata_fsl-fix-UAF-in-sata_fsl_port_stop-when-rmmod-sa.patch
  (git-fixes CVE-2021-47549 bsc#1225508).
- Update
  patches.suse/sched-scs-Reset-task-stack-state-in-bringup_cpu.patch
  (git-fixes CVE-2021-47553 bsc#1225464).
- Update
  patches.suse/scsi-core-Put-LLD-module-refcnt-after-SCSI-device-is.patch
  (stable-5.14.17 CVE-2021-47480 bsc#1225322).
- Update
  patches.suse/scsi-iscsi-Fix-iscsi_task-use-after-free.patch
  (stable-5.14.12 CVE-2021-47427 bsc#1225225).
- Update
  patches.suse/scsi-mpt3sas-Fix-kernel-panic-during-drive-powercycle-test
  (git-fixes CVE-2021-47565 bsc#1225384).
- Update
  patches.suse/scsi-pm80xx-Do-not-call-scsi_remove_host-in-pm8001_alloc
  (git-fixes CVE-2021-47503 bsc#1225374).
- Update
  patches.suse/scsi-qla2xxx-Fix-a-memory-leak-in-an-error-path-of-q.patch
  (stable-5.14.15 CVE-2021-47473 bsc#1225192).
- Update
  patches.suse/sctp-break-out-if-skb_header_pointer-returns-NULL-in.patch
  (stable-5.14.10 CVE-2021-47397 bsc#1225082).
- Update
  patches.suse/serial-core-fix-transmit-buffer-reset-and-memleak.patch
  (git-fixes CVE-2021-47527 bsc#1194288).
- Update
  patches.suse/serial-liteuart-Fix-NULL-pointer-dereference-in-remo.patch
  (git-fixes CVE-2021-47526 bsc#1225376).
- Update
  patches.suse/serial-liteuart-fix-minor-number-leak-on-probe-error.patch
  (git-fixes CVE-2021-47524 bsc#1225377).
- Update
  patches.suse/serial-liteuart-fix-use-after-free-and-memleak-on-un.patch
  (git-fixes CVE-2021-47525 bsc#1225441).
- Update
  patches.suse/spi-Fix-deadlock-when-adding-SPI-controllers-on-SPI-.patch
  (stable-5.14.15 CVE-2021-47469 bsc#1225347).
- Update
  patches.suse/staging-greybus-uart-fix-tty-use-after-free.patch
  (stable-5.14.9 CVE-2021-47358 bsc#1224920).
- Update
  patches.suse/staging-rtl8712-fix-use-after-free-in-rtl8712_dl_fw.patch
  (git-fixes stable-5.14.18 CVE-2021-47479 bsc#1224911).
- Update
  patches.suse/tcp-fix-page-frag-corruption-on-page-fault.patch
  (git-fixes CVE-2021-47544 bsc#1225463).
- Update
  patches.suse/tty-Fix-out-of-bound-vmalloc-access-in-imageblit.patch
  (stable-5.14.10 CVE-2021-47383 bsc#1225208).
- Update
  patches.suse/usb-cdnsp-Fix-a-NULL-pointer-dereference-in-cdnsp_en.patch
  (git-fixes CVE-2021-47528 bsc#1225368).
- Update
  patches.suse/usb-chipidea-ci_hdrc_imx-Also-search-for-phys-phandl.patch
  (git-fixes stable-5.14.12 CVE-2021-47413 bsc#1225333).
- Update
  patches.suse/usb-dwc2-check-return-value-after-calling-platform_g.patch
  (stable-5.14.11 CVE-2021-47409 bsc#1225330).
- Update patches.suse/usb-musb-dsps-Fix-the-probe-error-path.patch
  (git-fixes stable-5.14.14 CVE-2021-47436 bsc#1225244).
- Update patches.suse/usbnet-sanity-check-for-maxpacket.patch
  (stable-5.14.16 CVE-2021-47495 bsc#1225351).
- Update
  patches.suse/userfaultfd-fix-a-race-between-writeprotect-and-exit.patch
  (stable-5.14.15 CVE-2021-47461 bsc#1225249).
- Update
  patches.suse/vdpa_sim-avoid-putting-an-uninitialized-iova_domain.patch
  (git-fixes CVE-2021-47554 bsc#1225466).
- Update
  patches.suse/virtio-net-fix-pages-leaking-when-building-skb-in-bi.patch
  (stable-5.14.9 CVE-2021-47367 bsc#1225123).
- Update
  patches.suse/x86-entry-Clear-X86_FEATURE_SMAP-when-CONFIG_X86_SMA.patch
  (stable-5.14.12 CVE-2021-47430 bsc#1225228).
- Update
  patches.suse/xhci-Fix-command-ring-pointer-corruption-while-abort.patch
  (stable-5.14.14 CVE-2021-47434 bsc#1225232).
- commit 3a2e44b

- blacklist.conf: add fix that requires absent infrastruucture
- commit dbb8058

- scsi: lpfc: Copyright updates for 14.4.0.2 patches
  (bsc#1225842).
- scsi: lpfc: Update lpfc version to 14.4.0.2 (bsc#1225842).
- scsi: lpfc: Add support for 32 byte CDBs (bsc#1225842).
- scsi: lpfc: Change lpfc_hba hba_flag member into a bitmask
  (bsc#1225842).
  Refresh:
  - patches.suse/lpfc-reintroduce-old-irq-probe-logic.patch
- scsi: lpfc: Introduce rrq_list_lock to protect active_rrq_list
  (bsc#1225842).
- scsi: lpfc: Clear deferred RSCN processing flag when driver
  is unloading (bsc#1225842).
- scsi: lpfc: Update logging of protection type for T10 DIF I/O
  (bsc#1225842).
- scsi: lpfc: Change default logging level for unsolicited CT
  MIB commands (bsc#1225842).
- commit 5e95ee6

- Update
  patches.suse/1321-drm-msm-devfreq-Fix-OPP-refcnt-leak.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225444
  CVE-2021-47532).
- Update
  patches.suse/1322-drm-msm-Fix-mmap-to-include-VM_IO-and-VM_DONTDUMP.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225443
  CVE-2021-47531).
- Update
  patches.suse/1323-drm-msm-Fix-wait_fence-submitqueue-leak.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225442
  CVE-2021-47530).
- Update
  patches.suse/1622-drm-gma500-Fix-WARN_ON-lock-magic-lock-error.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 jsc#PED-2849
  bsc#1223489 CVE-2022-48633).
- Update
  patches.suse/ACPI-LPIT-Avoid-u32-multiplication-overflow.patch
  (git-fixes bsc#1224627 CVE-2023-52683).
- Update
  patches.suse/ACPI-processor_idle-Fix-memory-leak-in-acpi_processo.patch
  (git-fixes bsc#1223043 CVE-2024-26894).
- Update
  patches.suse/ACPI-video-check-for-error-while-searching-for-backl.patch
  (git-fixes bsc#1224686 CVE-2023-52693).
- Update
  patches.suse/ALSA-hda-Do-not-unset-preset-when-cleaning-up-codec.patch
  (git-fixes bsc#1225486 CVE-2023-52736).
- Update
  patches.suse/ALSA-hda-Fix-possible-null-ptr-deref-when-assigning-.patch
  (git-fixes bsc#1225554 CVE-2023-52806).
- Update
  patches.suse/ALSA-hda-intel-sdw-acpi-fix-usage-of-device_get_name.patch
  (git-fixes CVE-2024-36955).
- Update
  patches.suse/ALSA-pcm-oss-Fix-negative-period-buffer-sizes.patch
  (git-fixes bsc#1225411 CVE-2021-47511).
- Update
  patches.suse/ALSA-pcm-oss-Limit-the-period-size-to-16MB.patch
  (git-fixes bsc#1225409 CVE-2021-47509).
- Update
  patches.suse/ALSA-usb-audio-Stop-parsing-channels-bits-when-all-c.patch
  (git-fixes bsc#1224803 CVE-2024-27436).
- Update
  patches.suse/ARM-9381-1-kasan-clear-stale-stack-poison.patch
  (git-fixes bsc#1225715 CVE-2024-36906).
- Update
  patches.suse/ASoC-SOF-Fix-DSP-oops-stack-dump-output-contents.patch
  (git-fixes stable-5.14.10 bsc#1225206 CVE-2021-47381).
- Update
  patches.suse/ASoC-codecs-wcd934x-handle-channel-mappping-list-cor.patch
  (git-fixes bsc#1225369 CVE-2021-47502).
- Update
  patches.suse/Bluetooth-Avoid-potential-use-after-free-in-hci_erro.patch
  (git-fixes bsc#1222413 CVE-2024-26801).
- Update
  patches.suse/Bluetooth-Fix-memory-leak-in-hci_req_sync_complete.patch
  (git-fixes bsc#1224571 CVE-2024-35978).
- Update
  patches.suse/Bluetooth-L2CAP-Fix-not-validating-setsockopt-user-i.patch
  (git-fixes bsc#1224579 CVE-2024-35965).
- Update
  patches.suse/Bluetooth-RFCOMM-Fix-not-validating-setsockopt-user-.patch
  (git-fixes bsc#1224576 CVE-2024-35966).
- Update
  patches.suse/Bluetooth-SCO-Fix-not-validating-setsockopt-user-inp.patch
  (git-fixes bsc#1224587 CVE-2024-35967).
- Update
  patches.suse/Bluetooth-btintel-Fix-null-ptr-deref-in-btintel_read.patch
  (stable-fixes bsc#1224640 CVE-2024-35933).
- Update
  patches.suse/Bluetooth-btusb-Add-date-evt_skb-is-NULL-check.patch
  (git-fixes bsc#1225595 CVE-2023-52833).
- Update
  patches.suse/Bluetooth-hci_core-Fix-possible-buffer-overflow.patch
  (git-fixes CVE-2024-26889).
- Update
  patches.suse/Bluetooth-hci_event-Fix-handling-of-HCI_EV_IO_CAPA_R.patch
  (git-fixes bsc#1224723 CVE-2024-27416).
- Update
  patches.suse/Bluetooth-hci_sock-Fix-not-validating-setsockopt-use.patch
  (git-fixes bsc#1224582 CVE-2024-35963).
- Update
  patches.suse/Bluetooth-l2cap-fix-null-ptr-deref-in-l2cap_chan_tim.patch
  (git-fixes bsc#1224177 CVE-2024-27399).
- Update
  patches.suse/Bluetooth-msft-fix-slab-use-after-free-in-msft_do_cl.patch
  (git-fixes bsc#1225502 CVE-2024-36012).
- Update
  patches.suse/Bluetooth-qca-add-missing-firmware-sanity-checks.patch
  (git-fixes bsc#1225722 CVE-2024-36880).
- Update
  patches.suse/Bluetooth-qca-fix-NULL-deref-on-non-serdev-suspend.patch
  (git-fixes bsc#1224509 CVE-2024-35851).
- Update
  patches.suse/Bluetooth-qca-fix-firmware-check-error-path.patch
  (git-fixes CVE-2024-36942).
- Update
  patches.suse/Bluetooth-qca-fix-info-leak-when-fetching-fw-build-i.patch
  (git-fixes bsc#1225720 CVE-2024-36032).
- Update
  patches.suse/Fix-page-corruption-caused-by-racy-check-in-__free_pages.patch
  (bsc#1208149 bsc#1225118 CVE-2023-52739).
- Update
  patches.suse/HID-amd_sfh-Fix-potential-NULL-pointer-dereference.patch
  (stable-5.14.10 bsc#1225205 CVE-2021-47380).
- Update
  patches.suse/HID-betop-fix-slab-out-of-bounds-Write-in-betop_prob.patch
  (stable-5.14.10 bsc#1225303 CVE-2021-47404).
- Update
  patches.suse/HID-bigbenff-prevent-null-pointer-dereference.patch
  (git-fixes bsc#1225437 CVE-2021-47522).
- Update
  patches.suse/HID-usbhid-free-raw_report-buffers-in-usbhid_stop.patch
  (stable-5.14.10 bsc#1225238 CVE-2021-47405).
- Update
  patches.suse/IB-IPoIB-Fix-legacy-IPoIB-due-to-wrong-number-of-que.patch
  (git-fixes bsc#1225032 CVE-2023-52745).
- Update
  patches.suse/IB-hfi1-Fix-a-memleak-in-init_credit_return.patch
  (git-fixes bsc#1222975 CVE-2024-26839).
- Update
  patches.suse/IB-hfi1-Fix-leak-of-rcvhdrtail_dummy_kvaddr.patch
  (jsc#SLE-19242 bsc#1225438 CVE-2021-47523).
- Update
  patches.suse/IB-hfi1-Restore-allocated-resources-on-failed-copyou.patch
  (git-fixes bsc#1224931 CVE-2023-52747).
- Update
  patches.suse/IB-mlx5-Fix-init-stage-error-handling-to-avoid-doubl.patch
  (git-fixes bsc#1225587 CVE-2023-52851).
- Update
  patches.suse/IB-qib-Protect-from-buffer-overflow-in-struct-qib_us.patch
  (stable-5.14.16 bsc#1224904 CVE-2021-47485).
- Update
  patches.suse/Input-synaptics-rmi4-fix-use-after-free-in-rmi_unreg.patch
  (git-fixes bsc#1224928 CVE-2023-52840).
- Update
  patches.suse/KVM-PPC-Book3S-HV-Fix-stack-handling-in-idle_kvm_sta.patch
  (stable-5.14.15 bko#206669 bsc#1174585 bsc#1192107
  CVE-2021-43056 bsc#1225341 CVE-2021-47465).
- Update
  patches.suse/KVM-SVM-fix-missing-sev_decommission-in-sev_receive_.patch
  (stable-5.14.10 bsc#1225126 CVE-2021-47389).
- Update
  patches.suse/KVM-arm64-Fix-host-stage-2-PGD-refcount.patch
  (stable-5.14.15 bsc#1225258 CVE-2021-47450).
- Update
  patches.suse/KVM-x86-Fix-stack-out-of-bounds-memory-access-from-i.patch
  (stable-5.14.10 bsc#1225125 CVE-2021-47390).
- Update
  patches.suse/KVM-x86-Handle-SRCU-initialization-failure-during-pa.patch
  (stable-5.14.10 bsc#1225306 CVE-2021-47407).
- Update
  patches.suse/NFC-digital-fix-possible-memory-leak-in-digital_in_s.patch
  (stable-5.14.14 bsc#1225263 CVE-2021-47442).
- Update
  patches.suse/NFC-digital-fix-possible-memory-leak-in-digital_tg_l.patch
  (stable-5.14.14 bsc#1225262 CVE-2021-47443).
- Update
  patches.suse/NFSv4.2-fix-nfs4_listxattr-kernel-BUG-at-mm-usercopy.patch
  (git-fixes bsc#1223113 CVE-2024-26870).
- Update
  patches.suse/PCI-PM-Drain-runtime-idle-callbacks-before-driver-re.patch
  (git-fixes bsc#1224738 CVE-2024-35809).
- Update
  patches.suse/RDMA-cma-Ensure-rdma_addr_cancel-happens-before-issu.patch
  (stable-5.14.10 bsc#1225318 CVE-2021-47391).
- Update
  patches.suse/RDMA-cma-Fix-listener-leak-in-rdma_cma_listen_on_all.patch
  (stable-5.14.10 bsc#1225320 CVE-2021-47392).
- Update patches.suse/RDMA-hfi1-Fix-kernel-pointer-leak.patch
  (stable-5.14.10 bsc#1225131 CVE-2021-47398).
- Update
  patches.suse/RDMA-irdma-Fix-KASAN-issue-with-tasklet.patch
  (git-fixes bsc#1222974 CVE-2024-26838).
- Update
  patches.suse/RDMA-irdma-Fix-potential-NULL-ptr-dereference.patch
  (git-fixes bsc#1225121 CVE-2023-52744).
- Update
  patches.suse/RDMA-mlx5-Fix-fortify-source-warning-while-accessing.patch
  (git-fixes bsc#1223203 CVE-2024-26907).
- Update
  patches.suse/RDMA-mlx5-Initialize-the-ODP-xarray-when-creating-an.patch
  (stable-5.14.16 bsc#1224910 CVE-2021-47481).
- Update
  patches.suse/Reapply-drm-qxl-simplify-qxl_fence_wait.patch
  (stable-fixes CVE-2024-36944).
- Update
  patches.suse/Revert-drm-amd-flush-any-delayed-gfxoff-on-suspend-e.patch
  (git-fixes bsc#1223137 CVE-2024-26916).
- Update
  patches.suse/Revert-drm-amd-pm-resolve-reboot-exception-for-si-ol.patch
  (git-fixes bsc#1224722 CVE-2023-52657).
- Update
  patches.suse/SUNRPC-Fix-RPC-client-cleaned-up-the-freed-pipefs-de.patch
  (git-fixes bsc#1225008 CVE-2023-52803).
- Update
  patches.suse/SUNRPC-fix-a-memleak-in-gss_import_v2_context.patch
  (git-fixes bsc#1223858 bsc#1223712 CVE-2023-52653).
- Update
  patches.suse/SUNRPC-fix-some-memleaks-in-gssx_dec_option_array.patch
  (git-fixes bsc#1223744 CVE-2024-27388).
- Update
  patches.suse/USB-core-Fix-access-violation-during-port-device-rem.patch
  (git-fixes bsc#1225734 CVE-2024-36896).
- Update
  patches.suse/USB-core-Fix-deadlock-in-usb_deauthorize_interface.patch
  (git-fixes bsc#1223671 CVE-2024-26934).
- Update
  patches.suse/aio-fix-use-after-free-due-to-missing-POLLFREE-handl.patch
  (CVE-2021-39698 bsc#1196956 bsc#1225400 CVE-2021-47505).
- Update
  patches.suse/arm64-hibernate-Fix-level3-translation-fault-in-swsu.patch
  (git-fixes bsc#1223748 CVE-2024-26989).
- Update
  patches.suse/atl1c-Work-around-the-DMA-RX-overflow-issue.patch
  (git-fixes bsc#1225599 CVE-2023-52834).
- Update
  patches.suse/audit-fix-possible-null-pointer-dereference-in-audit.patch
  (stable-5.14.15 bsc#1225393 CVE-2021-47464).
- Update
  patches.suse/ax25-fix-use-after-free-bugs-caused-by-ax25_ds_del_t.patch
  (git-fixes bsc#1224663 CVE-2024-35887).
- Update
  patches.suse/batman-adv-Avoid-infinite-loop-trying-to-resize-loca.patch
  (git-fixes bsc#1224566 CVE-2024-35982).
- Update patches.suse/binder-make-sure-fd-closes-complete.patch
  (stable-5.14.9 bsc#1225122 CVE-2021-47360).
- Update
  patches.suse/blk-cgroup-fix-UAF-by-grabbing-blkcg-lock-before-des.patch
  (stable-5.14.9 bsc#1225203 CVE-2021-47379).
- Update
  patches.suse/blk-mq-cancel-blk-mq-dispatch-work-in-both-blk_clean.patch
  (jsc#PED-1183 bsc#1225513 CVE-2021-47552).
- Update
  patches.suse/blktrace-Fix-uaf-in-blk_trace-access-after-removing-.patch
  (stable-5.14.9 bsc#1225193 CVE-2021-47375).
- Update
  patches.suse/block-don-t-call-rq_qos_ops-done_bio-if-the-bio-isn-.patch
  (stable-5.14.11 bsc#1225332 CVE-2021-47412).
- Update
  patches.suse/bpf-Add-oversize-check-before-call-kvcalloc.patch
  (stable-5.14.9 bsc#1225195 CVE-2021-47376).
- Update patches.suse/bpf-Check-bloom-filter-map-value-size.patch
  (bsc#1224488 CVE-2024-35905 bsc#1225766 CVE-2024-36918).
- Update
  patches.suse/bpf-s390-Fix-potential-memory-leak-about-jit_data.patch
  (stable-5.14.12 bsc#1225370 CVE-2021-47426).
- Update
  patches.suse/btrfs-fix-abort-logic-in-btrfs_replace_file_extents.patch
  (stable-5.14.14 bsc#1225392 CVE-2021-47433).
- Update
  patches.suse/btrfs-fix-information-leak-in-btrfs_ioctl_logical_to.patch
  (git-fixes bsc#1224733 CVE-2024-35849).
- Update
  patches.suse/btrfs-fix-re-dirty-process-of-tree-log-nodes.patch
  (bsc#1197915 bsc#1225410 CVE-2021-47510).
- Update
  patches.suse/btrfs-free-exchange-changeset-on-failures.patch
  (git-fixes bsc#1225408 CVE-2021-47508).
- Update
  patches.suse/can-dev-can_put_echo_skb-don-t-crash-kernel-if-can_p.patch
  (git-fixes bsc#1225000 CVE-2023-52878).
- Update
  patches.suse/can-isotp-isotp_sendmsg-add-result-check-for-wait_ev.patch
  (stable-5.14.15 bsc#1225235 CVE-2021-47457).
- Update
  patches.suse/can-j1939-j1939_netdev_start-fix-UAF-for-rx_kref-of-.patch
  (stable-5.14.15 bsc#1225253 CVE-2021-47459).
- Update
  patches.suse/can-pch_can-pch_can_rx_normal-fix-use-after-free.patch
  (git-fixes bsc#1225431 CVE-2021-47520).
- Update patches.suse/can-peak_pci-peak_pci_remove-fix-UAF.patch
  (stable-5.14.15 bsc#1225256 CVE-2021-47456).
- Update
  patches.suse/can-sja1000-fix-use-after-free-in-ems_pcmcia_add_car.patch
  (git-fixes bsc#1225435 CVE-2021-47521).
- Update
  patches.suse/ceph-blocklist-the-kclient-when-receiving-corrupted-snap-trace.patch
  (jsc#SES-1880 bsc#1225222 CVE-2023-52732).
- Update
  patches.suse/cfg80211-fix-management-registrations-locking.patch
  (git-fixes stable-5.14.16 bsc#1225450 CVE-2021-47494).
- Update
  patches.suse/cgroup-Fix-memory-leak-caused-by-missing-cgroup_bpf_.patch
  (stable-5.14.16 bsc#1224902 CVE-2021-47488).
- Update patches.suse/cifs-Fix-soft-lockup-during-fsstress.patch
  (stable-5.14.9 bsc#1225145 CVE-2021-47359).
- Update
  patches.suse/cifs-Fix-use-after-free-in-rdata-read_into_pages-.patch
  (git-fixes bsc#1225479 CVE-2023-52741).
- Update
  patches.suse/clk-Get-runtime-PM-before-walking-tree-during-disabl.patch
  (git-fixes bsc#1223762 CVE-2024-27004).
- Update
  patches.suse/clk-mediatek-clk-mt2701-Add-check-for-mtk_alloc_clk_.patch
  (git-fixes bsc#1225096 CVE-2023-52875).
- Update
  patches.suse/clk-mediatek-clk-mt6765-Add-check-for-mtk_alloc_clk_.patch
  (git-fixes bsc#1224937 CVE-2023-52870).
- Update
  patches.suse/clk-mediatek-clk-mt6779-Add-check-for-mtk_alloc_clk_.patch
  (git-fixes bsc#1225589 CVE-2023-52873).
- Update
  patches.suse/clk-mediatek-clk-mt6797-Add-check-for-mtk_alloc_clk_.patch
  (git-fixes bsc#1225086 CVE-2023-52865).
- Update
  patches.suse/clk-mediatek-clk-mt7629-Add-check-for-mtk_alloc_clk_.patch
  (git-fixes bsc#1225566 CVE-2023-52858).
- Update
  patches.suse/clk-mediatek-clk-mt7629-eth-Add-check-for-mtk_alloc_.patch
  (git-fixes bsc#1225036 CVE-2023-52876).
- Update
  patches.suse/clk-zynq-Prevent-null-pointer-dereference-caused-by-.patch
  (git-fixes bsc#1223717 CVE-2024-27037).
- Update
  patches.suse/comedi-Fix-memory-leak-in-compat_insnlist.patch
  (stable-5.14.9 bsc#1225158 CVE-2021-47364).
- Update patches.suse/comedi-dt9812-fix-DMA-buffers-on-stack.patch
  (git-fixes stable-5.14.18 bsc#1224912 CVE-2021-47477).
- Update
  patches.suse/comedi-ni_usb6501-fix-NULL-deref-in-command-paths.patch
  (git-fixes stable-5.14.18 bsc#1224913 CVE-2021-47476).
- Update
  patches.suse/comedi-vmk80xx-fix-bulk-buffer-overflow.patch
  (git-fixes stable-5.14.18 bsc#1224915 CVE-2021-47474).
- Update
  patches.suse/comedi-vmk80xx-fix-incomplete-endpoint-checking.patch
  (git-fixes bsc#1223698 CVE-2024-27001).
- Update
  patches.suse/comedi-vmk80xx-fix-transfer-buffer-overflows.patch
  (git-fixes stable-5.14.18 bsc#1224914 CVE-2021-47475).
- Update
  patches.suse/cpufreq-brcmstb-avs-cpufreq-add-check-for-cpufreq_cp.patch
  (git-fixes bsc#1223769 CVE-2024-27051).
- Update
  patches.suse/cpufreq-schedutil-Use-kobject-release-method-to-free.patch
  (stable-5.14.10 bsc#1225316 CVE-2021-47387).
- Update
  patches.suse/crypto-qat-resolve-race-condition-during-AER-recover.patch
  (git-fixes bsc#1223638 CVE-2024-26974).
- Update
  patches.suse/crypto-s390-aes-Fix-buffer-overread-in-CTR-mode.patch
  (git-fixes bsc#1224637 CVE-2023-52669).
- Update
  patches.suse/devlink-fix-netns-refcount-leak-in-devlink_nl_cmd_re.patch
  (git-fixes bsc#1225425 CVE-2021-47514).
- Update
  patches.suse/dm-call-the-resume-method-on-internal-suspend-65e8.patch
  (git-fixes bsc#1223188 CVE-2024-26880).
- Update
  patches.suse/dm-fix-mempool-NULL-pointer-race-when-completing-IO.patch
  (stable-5.14.14 bsc#1225247 CVE-2021-47435).
- Update
  patches.suse/dm-rq-don-t-queue-request-to-blk-mq-during-DM-suspen.patch
  (stable-5.14.14 bsc#1225357 CVE-2021-47498).
- Update
  patches.suse/dma-debug-prevent-an-error-message-from-causing-runt.patch
  (stable-5.14.9 bsc#1225191 CVE-2021-47374).
- Update patches.suse/dma-xilinx_dpdma-Fix-locking.patch
  (git-fixes bsc#1224559 CVE-2024-35990).
- Update
  patches.suse/dmaengine-fsl-qdma-Fix-a-memory-leak-related-to-the-.patch
  (git-fixes bsc#1224632 CVE-2024-35833).
- Update
  patches.suse/dmaengine-fsl-qdma-init-irq-after-reg-initialization.patch
  (git-fixes bsc#1222783 CVE-2024-26788).
- Update
  patches.suse/dmaengine-idxd-Fix-oops-during-rmmod-on-single-CPU-p.patch
  (git-fixes bsc#1224558 CVE-2024-35989).
- Update
  patches.suse/drm-amd-Fix-UBSAN-array-index-out-of-bounds-for-Pola.patch
  (git-fixes bsc#1225532 CVE-2023-52819).
- Update
  patches.suse/drm-amd-Fix-UBSAN-array-index-out-of-bounds-for-SMU7.patch
  (git-fixes bsc#1225530 CVE-2023-52818).
- Update patches.suse/drm-amd-amdgpu-fix-potential-memleak.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225379
  CVE-2021-47550).
- Update
  patches.suse/drm-amd-amdkfd-Fix-kernel-panic-when-reset-failed-an.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225510
  CVE-2021-47551).
- Update
  patches.suse/drm-amd-display-Atom-Integrated-System-Info-v2_2-for.patch
  (stable-fixes bsc#1225735 CVE-2024-36897).
- Update
  patches.suse/drm-amd-display-Avoid-NULL-dereference-of-timing-gen.patch
  (git-fixes bsc#1225478 CVE-2023-52753).
- Update
  patches.suse/drm-amd-display-Fix-a-potential-buffer-overflow-in-d.patch
  (git-fixes bsc#1223826 CVE-2024-27045).
- Update
  patches.suse/drm-amd-display-fix-a-NULL-pointer-dereference-in-am.patch
  (git-fixes bsc#1225041 CVE-2023-52773).
- Update
  patches.suse/drm-amd-pm-Update-intermediate-power-state-for-SI.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225153
  CVE-2021-47362).
- Update
  patches.suse/drm-amd-pm-fix-a-double-free-in-si_dpm_init.patch
  (git-fixes bsc#1224607 CVE-2023-52691).
- Update
  patches.suse/drm-amd-pm-fixes-a-random-hang-in-S4-for-SMU-v13.0.4.patch
  (stable-fixes bsc#1225705 CVE-2024-36026).
- Update
  patches.suse/drm-amdgpu-Fix-a-null-pointer-access-when-the-smc_rr.patch
  (git-fixes bsc#1225569 CVE-2023-52817).
- Update
  patches.suse/drm-amdgpu-Fix-potential-null-pointer-derefernce.patch
  (git-fixes bsc#1225565 CVE-2023-52814).
- Update
  patches.suse/drm-amdgpu-fence-Fix-oops-due-to-non-matching-drm_sc.patch
  (git-fixes bsc#1225005 CVE-2023-52738).
- Update patches.suse/drm-amdgpu-fix-gart.bo-pin_count-leak.patch
  (stable-5.14.13 bsc#1225390 CVE-2021-47431).
- Update
  patches.suse/drm-amdgpu-handle-the-case-of-pci_channel_io_frozen-.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225353
  CVE-2021-47421).
- Update
  patches.suse/drm-amdgpu-once-more-fix-the-call-oder-in-amdgpu_ttm.patch
  (git-fixes bsc#1224180 CVE-2024-27400).
- Update
  patches.suse/drm-amdgpu-validate-the-parameters-of-bo-mapping-ope.patch
  (git-fixes bsc#1223315 CVE-2024-26922).
- Update
  patches.suse/drm-amdgpu-vkms-fix-a-possible-null-pointer-derefere.patch
  (git-fixes bsc#1225568 CVE-2023-52815).
- Update
  patches.suse/drm-amdkfd-Confirm-list-is-non-empty-before-utilizin.patch
  (git-fixes bsc#1224617 CVE-2023-52678).
- Update
  patches.suse/drm-amdkfd-Fix-a-race-condition-of-vram-buffer-unref.patch
  (git-fixes bsc#1225076 CVE-2023-52825).
- Update
  patches.suse/drm-amdkfd-Fix-shift-out-of-bounds-issue.patch
  (git-fixes bsc#1225529 CVE-2023-52816).
- Update
  patches.suse/drm-amdkfd-fix-a-potential-ttm-sg-memory-leak.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225339
  CVE-2021-47420).
- Update
  patches.suse/drm-amdkfd-fix-svm_migrate_fini-warning.patch
  (stable-5.14.11 bsc#1225331 CVE-2021-47410).
- Update
  patches.suse/drm-arm-malidp-fix-a-possible-null-pointer-dereferen.patch
  (git-fixes bsc#1225593 CVE-2024-36014).
- Update patches.suse/drm-ast-Fix-soft-lockup.patch (git-fixes
  bsc#1224705 CVE-2024-35952).
- Update
  patches.suse/drm-bridge-it66121-Fix-invalid-connector-dereference.patch
  (git-fixes bsc#1224941 CVE-2023-52861).
- Update
  patches.suse/drm-bridge-lt8912b-Fix-crash-on-bridge-detach.patch
  (git-fixes bsc#1224932 CVE-2023-52856).
- Update
  patches.suse/drm-bridge-tpd12s015-Drop-buggy-__exit-annotation-fo.patch
  (git-fixes bsc#1224598 CVE-2023-52694).
- Update
  patches.suse/drm-client-Fully-protect-modes-with-dev-mode_config..patch
  (stable-fixes bsc#1224703 CVE-2024-35950).
- Update
  patches.suse/drm-edid-In-connector_bad_edid-cap-num_of_ext-by-num.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225243
  CVE-2021-47444).
- Update
  patches.suse/drm-i915-bios-Tolerate-devdata-NULL-in-intel_bios_en.patch
  (stable-fixes bsc#1223678 CVE-2024-26938).
- Update
  patches.suse/drm-i915-gt-Reset-queue_priority_hint-on-parking.patch
  (git-fixes bsc#1223677 CVE-2024-26937).
- Update
  patches.suse/drm-lima-fix-a-memleak-in-lima_heap_alloc.patch
  (git-fixes bsc#1224707 CVE-2024-35829).
- Update
  patches.suse/drm-mediatek-Fix-a-null-pointer-crash-in-mtk_drm_crt.patch
  (git-fixes bsc#1223048 CVE-2024-26874).
- Update
  patches.suse/drm-msm-Fix-null-pointer-dereference-on-pointer-edp.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225261
  CVE-2021-47445).
- Update
  patches.suse/drm-msm-a3xx-fix-error-handling-in-a3xx_gpu_init.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225260
  CVE-2021-47447).
- Update
  patches.suse/drm-msm-a4xx-fix-error-handling-in-a4xx_gpu_init.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225240
  CVE-2021-47446).
- Update
  patches.suse/drm-msm-a6xx-Allocate-enough-space-for-GMU-registers.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225446
  CVE-2021-47535).
- Update
  patches.suse/drm-mxsfb-Fix-NULL-pointer-dereference-crash-on-unlo.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225187
  CVE-2021-47471).
- Update
  patches.suse/drm-nouveau-debugfs-fix-file-release-memory-leak.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225366
  CVE-2021-47423).
- Update
  patches.suse/drm-nouveau-kms-nv50-fix-file-release-memory-leak.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225233
  CVE-2021-47422).
- Update patches.suse/drm-nv04-Fix-out-of-bounds-access.patch
  (git-fixes bsc#1223802 CVE-2024-27008).
- Update
  patches.suse/drm-panel-fix-a-possible-null-pointer-dereference.patch
  (git-fixes bsc#1225022 CVE-2023-52821).
- Update
  patches.suse/drm-panel-panel-tpo-tpg110-fix-a-possible-null-point.patch
  (git-fixes bsc#1225077 CVE-2023-52826).
- Update
  patches.suse/drm-radeon-fix-a-possible-null-pointer-dereference.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225230
  CVE-2022-48710).
- Update patches.suse/drm-radeon-possible-buffer-overflow.patch
  (git-fixes bsc#1225009 CVE-2023-52867).
- Update
  patches.suse/drm-tegra-dsi-Add-missing-check-for-of_find_device_b.patch
  (git-fixes bsc#1223770 CVE-2023-52650).
- Update
  patches.suse/drm-tegra-rgb-Fix-missing-clk_put-in-the-error-handl.patch
  (git-fixes bsc#1224445 CVE-2023-52661).
- Update
  patches.suse/drm-ttm-fix-memleak-in-ttm_transfered_destroy.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225436
  CVE-2021-47490).
- Update
  patches.suse/drm-vc4-don-t-check-if-plane-state-fb-state-fb.patch
  (stable-fixes bsc#1224650 CVE-2024-35932).
- Update
  patches.suse/drm-vc4-kms-Add-missing-drm_crtc_commit_put.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225
  CVE-2021-47534).
- Update
  patches.suse/drm-vc4-kms-Clear-the-HVS-FIFO-commit-pointer-once-d.patch
  (jsc#PED-1166 jsc#PED-1168 jsc#PED-1170 jsc#PED-1218
  jsc#PED-1220 jsc#PED-1222 jsc#PED-1223 jsc#PED-1225 bsc#1225445
  CVE-2021-47533).
- Update
  patches.suse/drm-vmwgfx-Create-debugfs-ttm_resource_manager-entry.patch
  (git-fixes bsc#1223718 CVE-2024-26940).
- Update
  patches.suse/drm-vmwgfx-fix-a-memleak-in-vmw_gmrid_man_get_node.patch
  (git-fixes bsc#1224449 CVE-2023-52662).
- Update
  patches.suse/dyndbg-fix-old-BUG_ON-in-control-parser.patch
  (stable-fixes bsc#1224647 CVE-2024-35947).
- Update
  patches.suse/enetc-Fix-illegal-access-when-reading-affinity_hint.patch
  (stable-5.14.9 bsc#1225161 CVE-2021-47368).
- Update
  patches.suse/ethtool-ioctl-fix-potential-NULL-deref-in-ethtool_se.patch
  (jsc#SLE-19253 bsc#1225383 CVE-2021-47556).
- Update
  patches.suse/ext4-add-error-checking-to-ext4_ext_replay_set_ibloc.patch
  (stable-5.14.10 bsc#1225304 CVE-2021-47406).
- Update
  patches.suse/fbdev-Fix-invalid-page-access-after-closing-deferred.patch
  (bsc#1207284 bsc#1224929 CVE-2023-52731).
- Update
  patches.suse/fbdev-imsttfb-fix-a-resource-leak-in-probe.patch
  (git-fixes bsc#1225031 CVE-2023-52838).
- Update
  patches.suse/fbdev-savage-Error-out-if-pixclock-equals-zero.patch
  (git-fixes bsc#1222770 CVE-2024-26778).
- Update
  patches.suse/fbdev-sis-Error-out-if-pixclock-equals-zero.patch
  (git-fixes bsc#1222765 CVE-2024-26777).
- Update
  patches.suse/fbmon-prevent-division-by-zero-in-fb_videomode_from_.patch
  (stable-fixes bsc#1224660 CVE-2024-35922).
- Update
  patches.suse/firewire-ohci-mask-bus-reset-interrupts-between-ISR-.patch
  (stable-fixes CVE-2024-36950).
- Update
  patches.suse/fs-jfs-Add-check-for-negative-db_l2nbperpage.patch
  (git-fixes bsc#1225557 CVE-2023-52810).
- Update
  patches.suse/fs-jfs-Add-validity-check-for-db_maxag-and-db_agpref.patch
  (git-fixes bsc#1225550 CVE-2023-52804).
- Update patches.suse/gfs2-ignore-negated-quota-changes.patch
  (git-fixes bsc#1225560 CVE-2023-52759).
- Update
  patches.suse/hid-cp2112-Fix-duplicate-workqueue-initialization.patch
  (git-fixes bsc#1224988 CVE-2023-52853).
- Update
  patches.suse/hwmon-mlxreg-fan-Return-non-zero-value-when-fan-curr.patch
  (git-fixes stable-5.14.10 bsc#1225321 CVE-2021-47393).
- Update
  patches.suse/hwmon-w83791d-Fix-NULL-pointer-dereference-by-removi.patch
  (stable-5.14.10 bsc#1225268 CVE-2021-47386).
- Update
  patches.suse/hwmon-w83792d-Fix-NULL-pointer-dereference-by-removi.patch
  (stable-5.14.10 bsc#1225210 CVE-2021-47385).
- Update
  patches.suse/hwmon-w83793-Fix-NULL-pointer-dereference-by-removin.patch
  (stable-5.14.10 bsc#1225209 CVE-2021-47384).
- Update
  patches.suse/i2c-acpi-fix-resource-leak-in-reconfiguration-device.patch
  (git-fixes stable-5.14.12 bsc#1225223 CVE-2021-47425).
- Update
  patches.suse/i2c-core-Run-atomic-i2c-xfer-when-preemptible.patch
  (git-fixes bsc#1225108 CVE-2023-52791).
- Update
  patches.suse/i2c-smbus-fix-NULL-function-pointer-dereference.patch
  (git-fixes bsc#1224567 CVE-2024-35984).
- Update
  patches.suse/i3c-master-mipi-i3c-hci-Fix-a-kernel-panic-for-acces.patch
  (git-fixes bsc#1225570 CVE-2023-52763).
- Update
  patches.suse/i3c-mipi-i3c-hci-Fix-out-of-bounds-access-in-hci_dma.patch
  (git-fixes CVE-2023-52766).
- Update
  patches.suse/i40e-Fix-NULL-pointer-dereference-in-i40e_dbg_dump_d.patch
  (jsc#SLE-18378 bsc#1225361 CVE-2021-47501).
- Update
  patches.suse/i40e-Fix-freeing-of-uninitialized-misc-IRQ-vector.patch
  (stable-5.14.12 bsc#1225367 CVE-2021-47424).
- Update
  patches.suse/i915-perf-Fix-NULL-deref-bugs-with-drm_dbg-calls.patch
  (git-fixes bsc#1225106 CVE-2023-52788).
- Update
  patches.suse/ice-Avoid-crash-from-unnecessary-IDA-free.patch
  (stable-5.14.15 bsc#1225239 CVE-2021-47453).
- Update
  patches.suse/ice-Do-not-use-WQ_MEM_RECLAIM-flag-for-workqueue.patch
  (jsc#PED-376 bsc#1225003 CVE-2023-52743).
- Update patches.suse/ice-avoid-bpf_prog-refcount-underflow.patch
  (jsc#SLE-18375 bsc#1225500 CVE-2021-47563).
- Update
  patches.suse/ice-fix-locking-for-Tx-timestamp-tracking-flush.patch
  (stable-5.14.14 bsc#1225259 CVE-2021-47449).
- Update patches.suse/ice-fix-vsi-txq_map-sizing.patch
  (jsc#SLE-18375 bsc#1225499 CVE-2021-47562).
- Update
  patches.suse/ice-switch-fix-potential-memleak-in-ice_add_adv_reci.patch
  (jsc#PED-376 bsc#1225095 CVE-2022-48709).
- Update
  patches.suse/iio-accel-kxcjk-1013-Fix-possible-memory-leak-in-pro.patch
  (git-fixes bsc#1225358 CVE-2021-47499).
- Update
  patches.suse/iio-adis16475-fix-deadlock-on-frequency-set.patch
  (git-fixes stable-5.14.14 bsc#1225245 CVE-2021-47437).
- Update
  patches.suse/iio-core-fix-memleak-in-iio_device_register_sysfs.patch
  (git-fixes bsc#1222960 CVE-2023-52643).
- Update
  patches.suse/iio-mma8452-Fix-trigger-reference-couting.patch
  (git-fixes bsc#1225360 CVE-2021-47500).
- Update
  patches.suse/init-main.c-Fix-potential-static_command_line-memory.patch
  (git-fixes bsc#1223747 CVE-2024-26988).
- Update
  patches.suse/io_uring-ensure-task_work-gets-run-as-part-of-cancel.patch
  (bsc#1205205 bsc#1225382 CVE-2021-47504).
- Update
  patches.suse/io_uring-fail-cancellation-for-EXITING-tasks.patch
  (bsc#1205205 bsc#1225515 CVE-2021-47569).
- Update
  patches.suse/ipack-ipoctal-fix-module-reference-leak.patch
  (stable-5.14.10 bsc#1225241 CVE-2021-47403).
- Update
  patches.suse/ipack-ipoctal-fix-stack-information-leak.patch
  (stable-5.14.10 bsc#1225242 CVE-2021-47401).
- Update
  patches.suse/irqchip-gic-v3-its-Fix-potential-VPE-leak-on-error.patch
  (stable-5.14.9 bsc#1225190 CVE-2021-47373).
- Update
  patches.suse/irqchip-gic-v3-its-Prevent-double-free-on-error.patch
  (git-fixes bsc#1224697 CVE-2024-35847).
- Update
  patches.suse/isdn-mISDN-Fix-sleeping-function-called-from-invalid.patch
  (stable-5.14.15 bsc#1225346 CVE-2021-47468).
- Update
  patches.suse/isofs-Fix-out-of-bound-access-for-corrupted-isofs-im.patch
  (stable-5.14.18 bsc#1225198 CVE-2021-47478).
- Update
  patches.suse/iwlwifi-Fix-memory-leaks-in-error-handling-path.patch
  (git-fixes bsc#1225373 CVE-2021-47529).
- Update
  patches.suse/iwlwifi-mvm-Fix-possible-NULL-dereference.patch
  (git-fixes stable-5.14.12 bsc#1225335 CVE-2021-47415).
- Update
  patches.suse/ixgbe-Fix-NULL-pointer-dereference-in-ixgbe_xdp_setu.patch
  (stable-5.14.10 bsc#1225328 CVE-2021-47399).
- Update
  patches.suse/jfs-fix-array-index-out-of-bounds-in-dbFindLeaf.patch
  (git-fixes bsc#1225472 CVE-2023-52799).
- Update
  patches.suse/jfs-fix-array-index-out-of-bounds-in-diAlloc.patch
  (git-fixes bsc#1225553 CVE-2023-52805).
- Update
  patches.suse/kprobes-Fix-possible-use-after-free-issue-on-kprobe-registration.patch
  (git-fixes bsc#1224676 CVE-2024-35955).
- Update
  patches.suse/kunit-fix-reference-count-leak-in-kfree_at_end.patch
  (stable-5.14.15 bsc#1225344 CVE-2021-47467).
- Update patches.suse/libbpf-Fix-memory-leak-in-strset.patch
  (git-fixes stable-5.14.12 bsc#1225227 CVE-2021-47417).
- Update
  patches.suse/mac80211-fix-use-after-free-in-CCMP-GCMP-RX.patch
  (git-fixes stable-5.14.10 bsc#1225214 CVE-2021-47388).
- Update
  patches.suse/mac80211-hwsim-fix-late-beacon-hrtimer-handling.patch
  (git-fixes stable-5.14.10 bsc#1225327 CVE-2021-47396).
- Update
  patches.suse/mac80211-limit-injected-vht-mcs-nss-in-ieee80211_par.patch
  (git-fixes stable-5.14.10 bsc#1225326 CVE-2021-47395).
- Update
  patches.suse/mcb-fix-error-handling-in-mcb_alloc_bus.patch
  (stable-5.14.9 bsc#1225151 CVE-2021-47361).
- Update
  patches.suse/md-Don-t-ignore-suspended-array-in-md_check_recovery-1baa.patch
  (git-fixes CVE-2024-26758).
- Update
  patches.suse/media-bttv-fix-use-after-free-error-due-to-btv-timeo.patch
  (git-fixes bsc#1225588 CVE-2023-52847).
- Update
  patches.suse/media-dvb-frontends-avoid-stack-overflow-warnings-wi.patch
  (git-fixes bsc#1223842 CVE-2024-27075).
- Update
  patches.suse/media-go7007-fix-a-memleak-in-go7007_load_encoder.patch
  (git-fixes bsc#1223844 CVE-2024-27074).
- Update
  patches.suse/media-gspca-cpia1-shift-out-of-bounds-in-set_flicker.patch
  (git-fixes bsc#1225571 CVE-2023-52764).
- Update
  patches.suse/media-imon-fix-access-to-invalid-resource-for-the-se.patch
  (git-fixes bsc#1225490 CVE-2023-52754).
- Update
  patches.suse/media-imx-csc-scaler-fix-v4l2_ctrl_handler-memory-le.patch
  (git-fixes bsc#1223779 CVE-2024-27076).
- Update patches.suse/media-ir_toy-fix-a-memleak-in-irtoy_tx.patch
  (git-fixes bsc#1223027 CVE-2024-26829).
- Update
  patches.suse/media-rc-bpf-attach-detach-requires-write-permission.patch
  (git-fixes bsc#1223031 CVE-2023-52642).
- Update
  patches.suse/media-ttpci-fix-two-memleaks-in-budget_av_attach.patch
  (git-fixes bsc#1223843 CVE-2024-27073).
- Update
  patches.suse/media-usbtv-Remove-useless-locks-in-usbtv_video_free.patch
  (git-fixes bsc#1223837 CVE-2024-27072).
- Update
  patches.suse/media-v4l2-mem2mem-fix-a-memleak-in-v4l2_m2m_registe.patch
  (git-fixes bsc#1223780 CVE-2024-27077).
- Update
  patches.suse/media-v4l2-tpg-fix-some-memleaks-in-tpg_alloc.patch
  (git-fixes bsc#1223781 CVE-2024-27078).
- Update
  patches.suse/media-vidtv-mux-Add-check-and-kfree-for-kstrdup.patch
  (git-fixes bsc#1225592 CVE-2023-52841).
- Update patches.suse/media-vidtv-psi-Add-check-for-kstrdup.patch
  (git-fixes bsc#1225590 CVE-2023-52844).
- Update
  patches.suse/mlxsw-spectrum-Protect-driver-from-buggy-firmware.patch
  (git-fixes bsc#1225495 CVE-2021-47560).
- Update
  patches.suse/mlxsw-thermal-Fix-out-of-bounds-memory-accesses.patch
  (stable-5.14.14 bsc#1225224 CVE-2021-47441).
- Update
  patches.suse/mm-mempolicy-do-not-allow-illegal-MPOL_F_NUMA_BALANC.patch
  (stable-5.14.15 bsc#1225250 CVE-2021-47462).
- Update
  patches.suse/mm-secretmem-fix-NULL-page-mapping-dereference-in-pa.patch
  (stable-5.14.15 bsc#1225127 CVE-2021-47463).
- Update
  patches.suse/mm-slub-fix-potential-memoryleak-in-kmem_cache_open.patch
  (stable-5.14.15 bsc#1225342 CVE-2021-47466).
- Update
  patches.suse/mm-slub-fix-potential-use-after-free-in-slab_debugfs.patch
  (stable-5.14.15 bsc#1225186 CVE-2021-47470).
- Update
  patches.suse/mmc-core-Avoid-negative-index-with-array-access.patch
  (git-fixes bsc#1224618 CVE-2024-35813).
- Update
  patches.suse/mmc-mmc_spi-fix-error-handling-in-mmc_spi_probe.patch
  (git-fixes bsc#1225483 CVE-2023-52708).
- Update
  patches.suse/mmc-sdhci-msm-pervent-access-to-suspended-controller.patch
  (git-fixes bsc#1225708 CVE-2024-36029).
- Update
  patches.suse/mmc-sdio-fix-possible-resource-leaks-in-some-error-p.patch
  (git-fixes bsc#1224956 CVE-2023-52730).
- Update
  patches.suse/mptcp-ensure-tx-skbs-always-have-the-MPTCP-ext.patch
  (stable-5.14.9 bsc#1225183 CVE-2021-47370).
- Update patches.suse/mptcp-fix-possible-stall-on-recvmsg.patch
  (stable-5.14.14 bsc#1225129 CVE-2021-47448).
- Update
  patches.suse/msft-hv-2940-hv_netvsc-Fix-race-condition-between-netvsc_probe-an.patch
  (git-fixes bsc#1222374 CVE-2024-26698).
- Update
  patches.suse/msft-hv-2971-net-mana-Fix-Rx-DMA-datasize-and-skb_over_panic.patch
  (git-fixes bsc#1224495 CVE-2024-35901).
- Update
  patches.suse/mt76-mt7915-fix-NULL-pointer-dereference-in-mt7915_g.patch
  (git-fixes bsc#1225386 CVE-2021-47540).
- Update
  patches.suse/net-USB-Fix-wrong-direction-WARNING-in-plusb.c.patch
  (git-fixes bsc#1225482 CVE-2023-52742).
- Update patches.suse/net-batman-adv-fix-error-handling.patch
  (git-fixes stable-5.14.16 bsc#1224909 CVE-2021-47482).
- Update
  patches.suse/net-bnx2x-Prevent-access-to-a-freed-page-in-page_poo.patch
  (bsc#1215322 bsc#1223049 CVE-2024-26859).
- Update
  patches.suse/net-dsa-felix-Fix-memory-leak-in-felix_setup_mmio_fi.patch
  (git-fixes bsc#1225380 CVE-2021-47513).
- Update
  patches.suse/net-dsa-microchip-Added-the-condition-for-scheduling.patch
  (stable-5.14.14 bsc#1225246 CVE-2021-47439).
- Update
  patches.suse/net-encx24j600-check-error-in-devm_regmap_init_encx2.patch
  (stable-5.14.14 bsc#1225248 CVE-2021-47440).
- Update
  patches.suse/net-hns3-do-not-allow-call-hns3_nic_net_open-repeate.patch
  (stable-5.14.10 bsc#1225329 CVE-2021-47400).
- Update
  patches.suse/net-ll_temac-platform_get_resource-replaced-by-wrong.patch
  (git-fixes bsc#1224615 CVE-2024-35796).
- Update patches.suse/net-macb-fix-use-after-free-on-rmmod.patch
  (stable-5.14.9 bsc#1225184 CVE-2021-47372).
- Update
  patches.suse/net-marvell-prestera-fix-double-free-issue-on-err-pa.patch
  (git-fixes bsc#1225501 CVE-2021-47564).
- Update
  patches.suse/net-mdiobus-Fix-memory-leak-in-__mdiobus_register.patch
  (stable-5.14.15 bsc#1225189 CVE-2021-47472).
- Update
  patches.suse/net-mlx4_en-Fix-an-use-after-free-bug-in-mlx4_en_try.patch
  (jsc#SLE-19256 bsc#1225453 CVE-2021-47541).
- Update
  patches.suse/net-mlx5e-Fix-memory-leak-in-mlx5_core_destroy_cq-er.patch
  (stable-5.14.14 bsc#1225229 CVE-2021-47438).
- Update
  patches.suse/net-openvswitch-fix-possible-memory-leak-in-ovs_mete.patch
  (git-fixes bsc#1224945 CVE-2023-52702).
- Update
  patches.suse/net-phy-fix-phy_get_internal_delay-accessing-an-empt.patch
  (git-fixes bsc#1223828 CVE-2024-27047).
- Update
  patches.suse/net-qlogic-qlcnic-Fix-a-NULL-pointer-dereference-in-.patch
  (git-fixes bsc#1225455 CVE-2021-47542).
- Update
  patches.suse/net-qualcomm-rmnet-fix-global-oob-in-rmnet_policy.patch
  (git-fixes bsc#1220363 CVE-2024-26597).
- Update
  patches.suse/net-sched-flower-protect-fl_walk-with-rcu.patch
  (stable-5.14.10 bsc#1225302 CVE-2021-47402).
- Update
  patches.suse/net-sched-fq_pie-prevent-dismantle-issue.patch
  (bsc#1207361 bsc#1225424 CVE-2021-47512).
- Update
  patches.suse/net-sched-sch_ets-don-t-peek-at-classes-beyond-nband.patch
  (bsc#1207361 bsc#1225468 CVE-2021-47557).
- Update
  patches.suse/net-sched-sch_taprio-properly-cancel-timer-from-tapr.patch
  (stable-5.14.12 bsc#1225338 CVE-2021-47419).
- Update
  patches.suse/net-smc-Fix-NULL-pointer-dereferencing-in-smc_vlan_by_tcpsk
  (git-fixes bsc#1225396 CVE-2021-47559).
- Update
  patches.suse/net-smc-fix-wrong-list_del-in-smc_lgr_cleanup_early
  (git-fixes bsc#1225447 CVE-2021-47536).
- Update
  patches.suse/net-stmmac-Disable-Tx-queues-when-reconfiguring-the-.patch
  (jsc#SLE-19033 bsc#1225492 CVE-2021-47558).
- Update
  patches.suse/net-tls-Fix-flipped-sign-in-tls_err_abort-calls.patch
  (stable-5.14.16 bsc#1225354 CVE-2021-47496).
- 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/net-vlan-fix-underflow-for-the-real_dev-refcnt.patch
  (git-fixes bsc#1225467 CVE-2021-47555).
- Update
  patches.suse/net_sched-fix-NULL-deref-in-fifo_set_limit.patch
  (stable-5.14.12 bsc#1225337 CVE-2021-47418).
- Update
  patches.suse/netfilter-conntrack-serialize-hash-resizes-and-clean.patch
  (stable-5.14.10 bsc#1225236 CVE-2021-47408).
- Update
  patches.suse/netfilter-nf_tables-skip-netdev-events-generated-on-.patch
  (stable-5.14.15 bsc#1225257 CVE-2021-47452).
- Update
  patches.suse/netfilter-nf_tables-unlink-table-before-deleting-it.patch
  (stable-5.14.10 bsc#1225323 CVE-2021-47394).
- Update
  patches.suse/netfilter-xt_IDLETIMER-fix-panic-that-occurs-when-ti.patch
  (stable-5.14.15 bsc#1225237 CVE-2021-47451).
- Update
  patches.suse/nexthop-Fix-division-by-zero-while-replacing-a-resil.patch
  (stable-5.14.9 bsc#1225156 CVE-2021-47363).
- Update
  patches.suse/nexthop-Fix-memory-leaks-in-nexthop-notification-cha.patch
  (stable-5.14.9 bsc#1225167 CVE-2021-47371).
- Update
  patches.suse/nfc-fix-potential-NULL-pointer-deref-in-nfc_genl_dum.patch
  (git-fixes bsc#1225372 CVE-2021-47518).
- Update
  patches.suse/nfc-nci-Fix-uninit-value-in-nci_dev_up-and-nci_ntf_p.patch
  (git-fixes bsc#1224479 CVE-2024-35915).
- Update
  patches.suse/nfp-Fix-memory-leak-in-nfp_cpp_area_cache_add.patch
  (git-fixes bsc#1225427 CVE-2021-47516).
- Update patches.suse/nfsd-Fix-nsfd-startup-race-again.patch
  (git-fixes bsc#1225405 CVE-2021-47507).
- Update
  patches.suse/nfsd-fix-use-after-free-due-to-delegation-race.patch
  (git-fixes bsc#1225404 CVE-2021-47506).
- Update
  patches.suse/nilfs2-fix-underflow-in-second-superblock-position-c.patch
  (git-fixes bsc#1225480 CVE-2023-52705).
- Update
  patches.suse/nouveau-dmem-handle-kcalloc-allocation-failure.patch
  (git-fixes CVE-2024-26943).
- Update
  patches.suse/nouveau-fix-instmem-race-condition-around-ptr-stores.patch
  (git-fixes bsc#1223633 CVE-2024-26984).
- Update
  patches.suse/nvme-fc-do-not-wait-in-vain-when-unloading-module.patch
  (git-fixes bsc#1223023 CVE-2024-26846).
- Update
  patches.suse/nvme-fix-reconnection-fail-due-to-reserved-tag-alloc.patch
  (git-fixes bsc#1224717 CVE-2024-27435).
- Update
  patches.suse/nvme-rdma-destroy-cm-id-before-destroy-qp-to-avoid-u.patch
  (bsc#1190569 stable-5.14.9 bsc#1225201 CVE-2021-47378).
- Update
  patches.suse/nvmem-Fix-shift-out-of-bound-UBSAN-with-byte-size-ce.patch
  (stable-5.14.14 bsc#1225355 CVE-2021-47497).
- Update
  patches.suse/ocfs2-fix-data-corruption-after-conversion-from-inli.patch
  (stable-5.14.15 bsc#1225251 CVE-2021-47460).
- Update
  patches.suse/ocfs2-fix-race-between-searching-chunks-and-release-.patch
  (stable-5.14.16 bsc#1225439 CVE-2021-47493).
- Update
  patches.suse/ocfs2-mount-fails-with-buffer-overflow-in-strlen.patch
  (stable-5.14.15 bsc#1225252 CVE-2021-47458).
- Update
  patches.suse/octeontx2-af-Fix-a-memleak-bug-in-rvu_mbox_init.patch
  (git-fixes bsc#1225375 CVE-2021-47537).
- Update
  patches.suse/octeontx2-af-Fix-possible-null-pointer-dereference.patch
  (stable-5.14.16 bsc#1224905 CVE-2021-47484).
- Update
  patches.suse/of-Fix-double-free-in-of_parse_phandle_with_args_map.patch
  (git-fixes bsc#1224508 CVE-2023-52679).
- Update
  patches.suse/padata-Fix-refcnt-handling-in-padata_free_shell.patch
  (git-fixes bsc#1225584 CVE-2023-52854).
- Update patches.suse/pci_iounmap-Fix-MMIO-mapping-leak.patch
  (git-fixes bsc#1223631 CVE-2024-26977).
- Update patches.suse/phy-mdio-fix-memory-leak.patch (git-fixes
  stable-5.14.12 bsc#1225336 CVE-2021-47416).
- Update
  patches.suse/pinctrl-core-delete-incorrect-free-in-pinctrl_enable.patch
  (git-fixes CVE-2024-36940).
- Update
  patches.suse/pinctrl-devicetree-fix-refcount-leak-in-pinctrl_dt_t.patch
  (git-fixes CVE-2024-36959).
- Update
  patches.suse/pinctrl-single-fix-potential-NULL-dereference.patch
  (git-fixes bsc#1224942 CVE-2022-48708).
- Update
  patches.suse/platform-x86-wmi-Fix-opening-of-char-device.patch
  (git-fixes bsc#1225132 CVE-2023-52864).
- Update
  patches.suse/power-supply-bq27xxx-i2c-Do-not-free-non-existing-IR.patch
  (git-fixes bsc#1224437 CVE-2024-27412).
- Update
  patches.suse/powerpc-64s-Fix-unrecoverable-MCE-calling-async-hand.patch
  (stable-5.14.12 bsc#1225388 CVE-2021-47429).
- Update
  patches.suse/powerpc-64s-fix-program-check-interrupt-emergency-st.patch
  (stable-5.14.12 bsc#1225387 CVE-2021-47428).
- Update
  patches.suse/powerpc-64s-interrupt-Fix-interrupt-exit-race-with-s.patch
  (bsc#1194869 bsc#1225471 CVE-2023-52740).
- Update
  patches.suse/powerpc-powernv-Add-a-null-pointer-check-in-opal_pow.patch
  (bsc#1181674 ltc#189159 git-fixes bsc#1224601 CVE-2023-52696).
- Update
  patches.suse/powerpc-pseries-Fix-potential-memleak-in-papr_get_at.patch
  (bsc#1200465 ltc#197256 jsc#SLE-18130 git-fixes bsc#1223756
  CVE-2022-48669).
- Update
  patches.suse/powerpc-pseries-iommu-LPAR-panics-during-boot-up-wit.patch
  (bsc#1222011 ltc#205900 CVE-2024-36926).
- Update
  patches.suse/powerpc-smp-do-not-decrement-idle-task-preempt-count.patch
  (stable-5.14.15 bsc#1225255 CVE-2021-47454).
- Update
  patches.suse/ppdev-Add-an-error-check-in-register_device.patch
  (git-fixes bsc#1225640 CVE-2024-36015).
- Update
  patches.suse/pstore-ram_core-fix-possible-overflow-in-persistent_.patch
  (git-fixes bsc#1224728 CVE-2023-52685).
- Update
  patches.suse/pstore-zone-Add-a-null-pointer-check-to-the-psz_kmsg.patch
  (stable-fixes bsc#1224537 CVE-2024-35940).
- Update
  patches.suse/ptp-Fix-possible-memory-leak-in-ptp_clock_register.patch
  (stable-5.14.15 bsc#1225254 CVE-2021-47455).
- Update patches.suse/pwm-Fix-double-shift-bug.patch (git-fixes
  bsc#1225461 CVE-2023-52756).
- Update patches.suse/qibfs-fix-dentry-leak.patch (git-fixes
  CVE-2024-36947).
- Update
  patches.suse/regmap-Fix-possible-double-free-in-regcache_rbtree_e.patch
  (git-fixes stable-5.14.16 bsc#1224907 CVE-2021-47483).
- Update
  patches.suse/riscv-Flush-current-cpu-icache-before-other-cpus.patch
  (stable-5.14.12 bsc#1225334 CVE-2021-47414).
- Update
  patches.suse/riscv-bpf-Fix-potential-NULL-dereference.patch
  (stable-5.14.16 bsc#1224903 CVE-2021-47486).
- Update
  patches.suse/s390-Once-the-discipline-is-associated-with-the-device-de.patch
  (bsc#1141539 git-fixes bsc#1223819 CVE-2024-27054).
- Update
  patches.suse/s390-cio-Ensure-the-copied-buf-is-NUL-terminated.patch
  (git-fixes bsc#1223875 bsc#1225747 CVE-2024-36931).
- Update
  patches.suse/s390-dasd-protect-device-queue-against-concurrent-access.patch
  (git-fixes bsc#1217515 bsc#1225572 CVE-2023-52774).
- Update
  patches.suse/s390-decompressor-specify-__decompress-buf-len-to-avoid-overflow.patch
  (git-fixes bsc#1213863 bsc#1225488 CVE-2023-52733).
- Update
  patches.suse/s390-qeth-Fix-kernel-panic-after-setting-hsuid.patch
  (git-fixes bsc#1223879 bsc#1225775 CVE-2024-36928).
- Update
  patches.suse/s390-qeth-fix-NULL-deref-in-qeth_clear_working_pool_.patch
  (stable-5.14.9 bsc#1225164 CVE-2021-47369).
- Update
  patches.suse/s390-qeth-fix-deadlock-during-failing-recovery.patch
  (stable-5.14.10 bsc#1225207 CVE-2021-47382).
- Update
  patches.suse/s390-zcrypt-fix-reference-counting-on-zcrypt-card-objects.patch
  (git-fixes bsc#1223595 bsc#1223666 CVE-2024-26957).
- Update
  patches.suse/sata_fsl-fix-UAF-in-sata_fsl_port_stop-when-rmmod-sa.patch
  (git-fixes bsc#1225508 CVE-2021-47549).
- Update
  patches.suse/sched-psi-Fix-use-after-free-in-ep_remove_wait_queue.patch
  (bsc#1209799 bsc#1225109 CVE-2023-52707).
- Update
  patches.suse/sched-scs-Reset-task-stack-state-in-bringup_cpu.patch
  (git-fixes bsc#1225464 CVE-2021-47553).
- Update
  patches.suse/scsi-core-Put-LLD-module-refcnt-after-SCSI-device-is.patch
  (stable-5.14.17 bsc#1225322 CVE-2021-47480).
- Update
  patches.suse/scsi-hisi_sas-Set-debugfs_dir-pointer-to-NULL-after-removing-debugfs.patch
  (git-fixes bsc#1225555 CVE-2023-52808).
- Update
  patches.suse/scsi-ibmvfc-Remove-BUG_ON-in-the-case-of-an-empty-ev.patch
  (bsc#1209834 ltc#202097 bsc#1225559 CVE-2023-52811).
- Update
  patches.suse/scsi-iscsi-Fix-iscsi_task-use-after-free.patch
  (stable-5.14.12 bsc#1225225 CVE-2021-47427).
- Update
  patches.suse/scsi-libfc-Fix-potential-NULL-pointer-dereference-in-fc_lport_ptp_setup.patch
  (git-fixes bsc#1225556 CVE-2023-52809).
- Update
  patches.suse/scsi-lpfc-Fix-possible-memory-leak-in-lpfc_rcv_padis.patch
  (bsc#1220021 bsc#1224651 CVE-2024-35930).
- Update
  patches.suse/scsi-lpfc-Move-NPIV-s-transport-unregistration-to-af.patch
  (bsc#1221777 CVE-2024-36952).
- Update
  patches.suse/scsi-lpfc-Release-hbalock-before-calling-lpfc_worker.patch
  (bsc#1221777 CVE-2024-36924).
- Update
  patches.suse/scsi-mpt3sas-Fix-kernel-panic-during-drive-powercycle-test
  (git-fixes bsc#1225384 CVE-2021-47565).
- Update
  patches.suse/scsi-pm80xx-Do-not-call-scsi_remove_host-in-pm8001_alloc
  (git-fixes bsc#1225374 CVE-2021-47503).
- Update
  patches.suse/scsi-qla2xxx-Fix-a-memory-leak-in-an-error-path-of-q.patch
  (stable-5.14.15 bsc#1225192 CVE-2021-47473).
- Update
  patches.suse/scsi-qla2xxx-Fix-command-flush-on-cable-pull.patch
  (bsc1221816 bsc#1223627 CVE-2024-26931).
- Update
  patches.suse/scsi-qla2xxx-Fix-double-free-of-the-ha-vp_map-pointer.patch
  (bsc1221816 bsc#1223626 CVE-2024-26930).
- Update
  patches.suse/sctp-break-out-if-skb_header_pointer-returns-NULL-in.patch
  (stable-5.14.10 bsc#1225082 CVE-2021-47397).
- Update
  patches.suse/serial-core-fix-transmit-buffer-reset-and-memleak.patch
  (git-fixes bsc#1194288 CVE-2021-47527).
- Update
  patches.suse/serial-liteuart-Fix-NULL-pointer-dereference-in-remo.patch
  (git-fixes bsc#1225376 CVE-2021-47526).
- Update
  patches.suse/serial-liteuart-fix-minor-number-leak-on-probe-error.patch
  (git-fixes bsc#1225377 CVE-2021-47524).
- Update
  patches.suse/serial-liteuart-fix-use-after-free-and-memleak-on-un.patch
  (git-fixes bsc#1225441 CVE-2021-47525).
- Update
  patches.suse/serial-mxs-auart-add-spinlock-around-changing-cts-st.patch
  (git-fixes bsc#1223757 CVE-2024-27000).
- Update
  patches.suse/serial-pmac_zilog-Remove-flawed-mitigation-for-rx-ir.patch
  (git-fixes bsc#1223754 CVE-2024-26999).
- Update
  patches.suse/soc-fsl-qbman-Always-disable-interrupts-when-taking-.patch
  (git-fixes bsc#1224699 CVE-2024-35806).
- Update
  patches.suse/soc-qcom-llcc-Handle-a-second-device-without-data-co.patch
  (git-fixes bsc#1225534 CVE-2023-52871).
- Update patches.suse/speakup-Avoid-crash-on-very-long-word.patch
  (git-fixes bsc#1223750 CVE-2024-26994).
- Update
  patches.suse/spi-Fix-deadlock-when-adding-SPI-controllers-on-SPI-.patch
  (stable-5.14.15 bsc#1225347 CVE-2021-47469).
- Update
  patches.suse/spi-spi-mt65xx-Fix-NULL-pointer-access-in-interrupt-.patch
  (git-fixes bsc#1223788 CVE-2024-27028).
- Update
  patches.suse/staging-greybus-uart-fix-tty-use-after-free.patch
  (stable-5.14.9 bsc#1224920 CVE-2021-47358).
- Update
  patches.suse/staging-rtl8712-fix-use-after-free-in-rtl8712_dl_fw.patch
  (git-fixes stable-5.14.18 bsc#1224911 CVE-2021-47479).
- Update
  patches.suse/tcp-fix-page-frag-corruption-on-page-fault.patch
  (git-fixes bsc#1225463 CVE-2021-47544).
- Update
  patches.suse/thermal-core-prevent-potential-string-overflow.patch
  (git-fixes bsc#1225044 CVE-2023-52868).
- Update
  patches.suse/tracing-trigger-Fix-to-return-error-if-failed-to-alloc-snapshot.patch
  (git-fixes CVE-2024-26920).
- Update
  patches.suse/tty-Fix-out-of-bound-vmalloc-access-in-imageblit.patch
  (stable-5.14.10 bsc#1225208 CVE-2021-47383).
- Update
  patches.suse/tty-n_gsm-fix-possible-out-of-bounds-in-gsm0_receive.patch
  (git-fixes bsc#1225642 CVE-2024-36016).
- Update
  patches.suse/tty-n_gsm-fix-race-condition-in-status-line-change-o.patch
  (git-fixes bsc#1225591 CVE-2023-52872).
- Update
  patches.suse/tty-n_gsm-require-CAP_NET_ADMIN-to-attach-N_GSM0710-.patch
  (bsc#1222619 CVE-2023-52880).
- Update
  patches.suse/tty-vcc-Add-check-for-kstrdup-in-vcc_probe.patch
  (git-fixes bsc#1225180 CVE-2023-52789).
- Update
  patches.suse/usb-cdc-wdm-close-race-between-read-and-workqueue.patch
  (git-fixes bsc#1224624 CVE-2024-35812).
- Update
  patches.suse/usb-cdns3-fix-memory-double-free-when-handle-zero-pa.patch
  (git-fixes bsc#1222513 CVE-2024-26748).
- Update
  patches.suse/usb-cdnsp-Fix-a-NULL-pointer-dereference-in-cdnsp_en.patch
  (git-fixes bsc#1225368 CVE-2021-47528).
- Update
  patches.suse/usb-chipidea-ci_hdrc_imx-Also-search-for-phys-phandl.patch
  (git-fixes stable-5.14.12 bsc#1225333 CVE-2021-47413).
- 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
  (stable-5.14.11 bsc#1225330 CVE-2021-47409).
- Update
  patches.suse/usb-dwc2-fix-possible-NULL-pointer-dereference-cause.patch
  (git-fixes bsc#1225583 CVE-2023-52855).
- Update
  patches.suse/usb-dwc2-host-Fix-dereference-issue-in-DDMA-completi.patch
  (git-fixes bsc#1223741 CVE-2024-26997).
- Update
  patches.suse/usb-gadget-f_ncm-Fix-UAF-ncm-object-at-re-bind-after.patch
  (stable-fixes bsc#1223752 CVE-2024-26996).
- Update
  patches.suse/usb-gadget-ncm-Avoid-dropping-datagrams-of-properly-.patch
  (git-fixes bsc#1224423 CVE-2024-27405).
- Update
  patches.suse/usb-gadget-ncm-Fix-handling-of-zero-block-length-pac.patch
  (git-fixes bsc#1224681 CVE-2024-35825).
- Update patches.suse/usb-musb-dsps-Fix-the-probe-error-path.patch
  (git-fixes stable-5.14.14 bsc#1225244 CVE-2021-47436).
- Update
  patches.suse/usb-typec-tcpm-Check-for-port-partner-validity-befor.patch
  (git-fixes bsc#1225748 CVE-2024-36893).
- Update
  patches.suse/usb-typec-tcpm-Fix-NULL-pointer-dereference-in-tcpm_.patch
  (git-fixes bsc#1224944 CVE-2023-52877).
- Update
  patches.suse/usb-udc-remove-warning-when-queue-disabled-ep.patch
  (stable-fixes bsc#1224739 CVE-2024-35822).
- Update
  patches.suse/usb-xhci-Add-error-handling-in-xhci_map_urb_for_dma.patch
  (git-fixes bsc#1223650 CVE-2024-26964).
- Update patches.suse/usbnet-sanity-check-for-maxpacket.patch
  (stable-5.14.16 bsc#1225351 CVE-2021-47495).
- Update
  patches.suse/userfaultfd-fix-a-race-between-writeprotect-and-exit.patch
  (stable-5.14.15 bsc#1225249 CVE-2021-47461).
- Update
  patches.suse/vdpa_sim-avoid-putting-an-uninitialized-iova_domain.patch
  (git-fixes bsc#1225466 CVE-2021-47554).
- Update
  patches.suse/virtio-net-fix-pages-leaking-when-building-skb-in-bi.patch
  (stable-5.14.9 bsc#1225123 CVE-2021-47367).
- Update
  patches.suse/vt-fix-unicode-buffer-corruption-when-deleting-chara.patch
  (git-fixes bsc#1224692 CVE-2024-35823).
- Update
  patches.suse/wifi-ath11k-decrease-MHI-channel-buffer-length-to-8K.patch
  (bsc#1207948 bsc#1224643 CVE-2024-35938).
- Update
  patches.suse/wifi-ath11k-fix-dfs-radar-event-locking.patch
  (git-fixes bsc#1224947 CVE-2023-52798).
- Update
  patches.suse/wifi-ath11k-fix-gtk-offload-status-event-locking.patch
  (git-fixes bsc#1224992 CVE-2023-52777).
- Update patches.suse/wifi-ath11k-fix-htt-pktlog-locking.patch
  (git-fixes CVE-2023-52800).
- Update
  patches.suse/wifi-b43-Stop-wake-correct-queue-in-DMA-Tx-path-when.patch
  (git-fixes bsc#1222961 CVE-2023-52644).
- Update
  patches.suse/wifi-iwlwifi-dbg-tlv-ensure-NUL-termination.patch
  (git-fixes bsc#1224731 CVE-2024-35845).
- Update
  patches.suse/wifi-iwlwifi-mvm-rfi-fix-potential-response-leaks.patch
  (git-fixes bsc#1224487 CVE-2024-35912).
- Update
  patches.suse/wifi-libertas-fix-some-memleaks-in-lbs_allocate_cmd_.patch
  (git-fixes bsc#1224622 CVE-2024-35828).
- Update
  patches.suse/wifi-mac80211-check-clear-fast-rx-for-non-4addr-sta-.patch
  (stable-fixes bsc#1224749 CVE-2024-35789).
- Update
  patches.suse/wifi-mac80211-don-t-return-unset-power-in-ieee80211_.patch
  (git-fixes bsc#1225577 CVE-2023-52832).
- Update
  patches.suse/wifi-mt76-mt7921e-fix-crash-in-chip-reset-fail.patch
  (bsc#1209980 bsc#1223895 CVE-2022-48705).
- Update
  patches.suse/wifi-nl80211-don-t-free-NULL-coalescing-rule.patch
  (git-fixes CVE-2024-36941).
- Update
  patches.suse/wifi-nl80211-reject-iftype-change-with-mesh-ID-chang.patch
  (git-fixes bsc#1224432 CVE-2024-27410).
- Update
  patches.suse/wifi-rtl8xxxu-add-cancel_work_sync-for-c2hcmd_work.patch
  (git-fixes bsc#1223829 CVE-2024-27052).
- Update
  patches.suse/wifi-wilc1000-fix-RCU-usage-in-connect-path.patch
  (git-fixes bsc#1223737 CVE-2024-27053).
- Update
  patches.suse/x86-entry-Clear-X86_FEATURE_SMAP-when-CONFIG_X86_SMA.patch
  (stable-5.14.12 bsc#1225228 CVE-2021-47430).
- Update
  patches.suse/x86-fpu-Keep-xfd_state-in-sync-with-MSR_IA32_XFD.patch
  (git-fixes bsc#1224732 CVE-2024-35801).
- Update
  patches.suse/x86-mm-Ensure-input-to-pfn_to_kaddr-is-treated-as-a-64-bit-type.patch
  (jsc#PED-7167 git-fixes bsc#1224442 CVE-2023-52659).
- Update
  patches.suse/xhci-Fix-command-ring-pointer-corruption-while-abort.patch
  (stable-5.14.14 bsc#1225232 CVE-2021-47434).
- commit 7e29329

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

- blacklist.conf: PPC fsl_msi is not used
- commit 346d509

- powerpc/uaccess: Use YZ asm constraint for ld (bsc#1194869).
- powerpc/uaccess: Fix build errors seen with GCC 13/14
  (bsc#1194869).
- commit 0f3f8d5

- nvmet: fix ns enable/disable possible hang (git-fixes).
- nvme-multipath: fix io accounting on failover (git-fixes).
- nvme: fix multipath batched completion accounting (git-fixes).
- commit dd54933

- netfilter: nf_tables: release mutex after nft_gc_seq_end from
  abort path (CVE-2024-26925 bsc#1223390).
- commit d38b98f

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

- bpf: Fix precision tracking for BPF_ALU | BPF_TO_BE | BPF_END
  (git-fixes).
- commit 53d4b05

- bpf: fix precision backtracking instruction iteration
  (bsc#1225756).
- commit 5aec043

- drivers/nvme: Add quirks for device 126f:2262 (git-fixes).
- nvme: fix miss command type check (git-fixes).
- commit b122221

- nvme: ensure disabling pairs with unquiesce (bsc#1224534).
- commit e08ce4d

- idpf: extend tx watchdog timeout (bsc#1224137).
- commit 65a74c5

- Bluetooth: ISO: Fix not validating setsockopt user input
  (bsc#1224581 CVE-2024-35964).
- commit cf9835d

- printk: Update @console_may_schedule in
  console_trylock_spinning() (bsc#1225616).
- commit 9f61f12

- Bluetooth: ISO: Add support for BT_PKT_STATUS (bsc#1224581
  CVE-2024-35964).
- commit 9488226

- Bluetooth: af_bluetooth: Make BT_PKT_STATUS generic (bsc#1224581
  CVE-2024-35964).
- Refresh
  patches.suse/Bluetooth-SCO-Fix-not-validating-setsockopt-user-inp.patch.
- commit 07d66e7

- swiotlb: extend buffer pre-padding to alloc_align_mask if necessary (bsc#1224331).
  Update patches.kabi/kABI-Work-around-kABI-changes-after-20347fca71a3-swi.patch (jsc#PED-3259, bsc#1224331).
- commit 861d481

- iommu/dma: Force swiotlb_max_mapping_size on an untrusted device (bsc#1224331)
- commit 00a5ac9

- swiotlb: Fix alignment checks when both allocation and DMA masks are (bsc#1224331)
- commit be23e64

- swiotlb: Honour dma_alloc_coherent() alignment in swiotlb_alloc() (bsc#1224331)
- commit ec1f4ec

- swiotlb: Fix double-allocation of slots due to broken alignment (bsc#1224331)
- commit cdb0386

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

- blacklist.conf: add commit for config change not needed
- commit 938b50b

- scsi: qla2xxx: Fix off by one in qla_edif_app_getstats()
  (git-fixes).
- scsi: sd: Unregister device if device_add_disk() failed in
  sd_probe() (git-fixes).
- scsi: mylex: Fix sysfs buffer lengths (git-fixes).
- scsi: core: Fix unremoved procfs host directory regression
  (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: mpt3sas: Prevent sending diag_reset when the controller
  is ready (git-fixes).
- scsi: core: Consult supported VPD page list prior to fetching
  page (git-fixes).
- scsi: libfc: Fix up timeout error in fc_fcp_rec_error()
  (git-fixes).
- scsi: libfc: Don't schedule abort twice (git-fixes).
- scsi: arcmsr: Support new PCI device IDs 1883 and 1886
  (git-fixes).
- commit f4328c2

- net: atlantic: eliminate double free in error handling logic
  (CVE-2023-52664 bsc#1224747).
- Refresh
  patches.suse/net-atlantic-Fix-DMA-mapping-for-PTP-hwts-ring.patch.
- commit 3161f6b

- blacklist.conf: arm: kernel does not support folios
- commit 44a14d2

- Delete BT and WiFi cleanup patches for netif_rx()
  Drop two cleanup patches that are likely broken: SLE15-SP5 kernel has
  no prerequisite commit baebdf48c3600 backported (yet):
  patches.suse/bluetooth-Use-netif_rx-d33d0dc9.patch
  patches.suse/wireless-Atheros-Use-netif_rx.patch
- commit d16d77f

- net: hns3: fix out-of-bounds access may occur when coalesce
  info is read via debugfs (CVE-2023-52807 bsc#1225097).
- commit 2628336

- tpm_tis_spi: Account for SPI header when allocating TPM SPI xfer (bsc#1225535)
- commit 58a5216

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

- cpumap: Zero-initialise xdp_rxq_info struct before running
  XDP program (bsc#1224718 CVE-2024-27431).
- commit 1d6e754

- blacklist.conf: optimization, not a fix
- commit 6b6d3e6

- PCI: dwc: Use the bitmap API to allocate bitmaps (git-fixes).
- commit 60a3fbf

- PCI: dwc: ep: Fix DBI access failure for drivers requiring
  refclk from host (git-fixes).
- PCI: dwc: Detect iATU settings after getting &amp;quot;addr_space&amp;quot;
  resource (git-fixes).
- commit a26d4db

- kABI: bpf: struct bpf_link and bpf_link_ops kABI workaround
  (bsc#1224531 CVE-2024-35860).
- commit 35186ef

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

- bpf: support deferring bpf_link dealloc to after RCU grace
  period (bsc#1224531 CVE-2024-35860).
- commit 5cff30d

- blacklist.conf: kABI
- commit f83467b

- tpm_tis_spi: Account for SPI header when allocating TPM SPI
  xfer buffer (git-fixes).
- commit 65639af

- drm/amd/display: Fix hang/underflow when transitioning to ODM4:1 (CVE-2023-52671 bsc#1224729).
- commit d5b1287

- blacklist.conf: Ignore all devicetree schemes changes
  We do not use them, so lets silence all git-fixes for them.
- commit c94d164

- drm/amd/display: Prevent crash when disable stream (CVE-2024-35799 bsc#1224740).
- commit 7764a6b

- drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr() (CVE-2024-35951 bsc#1224701).
- commit c3405cd

- efi/capsule-loader: fix incorrect allocation size (bsc#1224438
  CVE-2024-27413).
- commit bcbd0b7

- Update
  patches.suse/ring-buffer-Fix-a-race-between-readers-and-resize-checks.patch
  (bsc#1222893).
- commit 7df29b0

- drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag (CVE-2024-35817 bsc#1224736).
- commit 3fd949a

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

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

- Refresh patches.suse/x86-coco-Require-seeding-RNG-with-RDRAND-on-CoCo-systems.patch.
  Remove defined but unused variable warning.
- commit 2a387cc

- xfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr()
  (CVE-2023-52746 bsc#1225114)
- commit 1a99ba9

- mm/secretmem: fix GUP-fast succeeding on secretmem folios
  (CVE-2024-35872 bsc#1224530).
- commit 1a7a850

- Update CVE references (CVE-2024-35935 bsc#1224645)
  Update patches.suse/btrfs-send-handle-path-ref-underflow-in-header-itera.patch
  (CVE-2024-35935 bsc#1224645).
- commit 1afc656

- Update CVE references (CVE-2024-35936 bsc#1224644)
- Update patches.suse/btrfs-add-missing-mutex_unlock-in-btrfs_relocate_sys.patch
  (CVE-2024-35936 bsc#1224644).
- Update patches.suse/btrfs-handle-chunk-tree-lookup-error-in-btrfs_reloca.patch
  (CVE-2024-35936 bsc#1224644).
- commit 46ae3a6

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

- x86/bugs: Remove CONFIG_BHI_MITIGATION_AUTO and spectre_bhi=auto  (git-fixes).
- Update config files.
- commit 6a0eda0

- mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash
  work (CVE-2024-35852 bsc#1224502).
- mlxsw: spectrum_acl_tcam: Fix incorrect list API usage
  (CVE-2024-36006 bsc#1224541).
- mlxsw: spectrum_acl_tcam: Fix warning during rehash
  (CVE-2024-36007 bsc#1224543).
- mlxbf_gige: stop interface during shutdown (CVE-2024-35885
  bsc#1224519).
- mlxbf_gige: call request_irq() after NAPI initialized
  (CVE-2024-35907 bsc#1224492).
- mlxbf_gige: stop PHY during open() error paths (git-fixes).
- mlxbf_gige: Enable the GigE port in mlxbf_gige_open (git-fixes).
- mlxbf_gige: Fix intermittent no ip issue (git-fixes).
- ipvlan: add ipvlan_route_v6_outbound() helper (CVE-2023-52796
  bsc#1224930).
- commit de506c4

- tracing: Add MODULE_DESCRIPTION() to preemptirq_delay_test
  (git-fixes).
- commit 9feb6d7

- ring-buffer: Fix a race between readers and resize checks
  (git-fixes).
- commit 1627912

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

- blacklist.conf: add a not-relevant tracing commit
- commit 784f511

- dma-direct: Leak pages on dma_set_decrypted() failure (bsc#1224535 CVE-2024-35939).
- commit 7213b4b

- x86/coco: Require seeding RNG with RDRAND on CoCo systems (bsc#1224665 CVE-2024-35875).
- Refresh patches.suse/suse-hv-cc_attr_cpu_hotplug_disabled.patch.
- commit 234fdb1

- x86/sev: Check for MWAITX and MONITORX opcodes in the #VC handler (git-fixes).
- commit 450733a

- x86: Fix CPUIDLE_FLAG_IRQ_ENABLE leaking timer reprogram (git-fixes).
- commit bab84b2

- x86/tdx: Preserve shared bit on mprotect() (git-fixes).
- commit caf6529

- x86/sme: Fix memory encryption setting if enabled by default and not  overridden (git-fixes).
- commit 085895e

- x86/retpoline: Do the necessary fixup to the Zen3/4 srso return thunk  for !SRSO (git-fixes).
- commit 76ca8ec

- x86/boot: Ignore NMIs during very early boot (git-fixes).
- commit 20c646a

- x86/lib: Fix overflow when counting digits (git-fixes).
- commit 5eb97ad

- x86/mce: Make sure to grab mce_sysfs_mutex in set_bank() (git-fixes).
- commit f16b82f

- x86/bugs: Change commas to semicolons in 'spectre_v2' sysfs file (git-fixes).
- Refresh patches.suse/x86-bhi-Add-BHI-mitigation-knob.patch.
- commit 22da5da

- x86/nmi: Drop unused declaration of proc_nmi_enabled() (git-fixes).
- commit f63acb6

- blacklist.conf: Blacklist broken patch that gets reverted subsequently
- commit 5a2bbf2

- KVM: x86: Mark target gfn of emulated atomic instruction as
  dirty (bsc#1224638, CVE-2024-35804).
- commit e14475b

- Rename colliding patches before origin/cve/linux-5.14-LTSS -&amp;gt; SLE15-SP5 merge
- commit ead7031

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

- selinux: avoid dereference of garbage after mount failure
  (bsc#1224494 CVE-2024-35904).
- commit dad5bc3

- nilfs2: fix unexpected freezing of nilfs_segctor_sync()
  (git-fixes).
- nilfs2: fix use-after-free of timer for log writer thread
  (git-fixes).
- i3c: master: svc: fix invalidate IBI type and miss call client
  IBI handler (git-fixes).
- i3c: master: svc: change ENXIO to EAGAIN when IBI occurs during
  start frame (git-fixes).
- serial: kgdboc: Fix NMI-safety problems from keyboard reset code
  (stable-fixes).
- drm/amd/display: Fix division by zero in setup_dsc_config
  (stable-fixes).
- docs: kernel_include.py: Cope with docutils 0.21 (stable-fixes).
- pinctrl: core: handle radix_tree_insert() errors in
  pinctrl_register_one_pin() (stable-fixes).
- commit 062f495

- media: rkisp1: Fix IRQ handling due to shared interrupts
  (CVE-2023-52660 bsc#1224443).
- commit aadfd1f

- Input: cyapa - add missing input core locking to suspend/resume
  functions (git-fixes).
- Input: pm8xxx-vibrator - correct VIB_MAX_LEVELS calculation
  (git-fixes).
- Input: ims-pcu - fix printf string overflow (git-fixes).
- ASoC: tas2552: Add TX path for capturing AUDIO-OUT data
  (git-fixes).
- ALSA: core: Fix NULL module pointer assignment at card init
  (git-fixes).
- speakup: Fix sizeof() vs ARRAY_SIZE() bug (git-fixes).
- serial: sc16is7xx: fix bug in sc16is7xx_set_baud() when using
  prescaler (git-fixes).
- serial: 8250_bcm7271: use default_mux_rate if possible
  (git-fixes).
- tty: n_gsm: fix missing receive state reset after mode switch
  (git-fixes).
- tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
  (git-fixes).
- commit 1d7ff63

- kABI workaround for drivers/of/dynamic.c (CVE-2024-35879
  bsc#1224524).
- commit 2e9ad08

- pmdomain: ti: Add a null pointer check to the
  omap_prm_domain_init (CVE-2024-35943 bsc#1224649).
- commit aa89394

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

- of: dynamic: Synchronize of_changeset_destroy() with the
  devlink removals (CVE-2024-35879 bsc#1224524).
- driver core: Introduce device_link_wait_removal()
  (CVE-2024-35879 bsc#1224524).
- commit fe69cd8

- drivers/perf: hisi: use cpuhp_state_remove_instance_nocalls()
  for hisi_hns3_pmu uninit process (CVE-2023-52860 bsc#1224936).
- commit 1703104

- sched/topology: Optimize topology_span_sane() (bsc#1225053).
- cpumask: Add for_each_cpu_from() (bsc#1225053).
- commit f0643dd

- net/mlx5e: Fix mlx5e_priv_init() cleanup flow (CVE-2024-35959
  bsc#1224666).
- Refresh
  patches.suse/powerpc-Avoid-nmi_enter-nmi_exit-in-real-mode-interr.patch.
- Refresh
  patches.suse/powerpc-eeh-Permanently-disable-the-removed-device.patch.
- commit 2088b29

- mlxsw: spectrum_acl_tcam: Fix possible use-after-free during
  rehash (CVE-2024-35854 bsc#1224636).
- commit 0674818

- geneve: fix header validation in geneve[6]_xmit_skb
  (CVE-2024-35973 bsc#1224586).
- commit ef0dd47

- ipv6: fix potential &amp;quot;struct net&amp;quot; leak in inet6_rtm_getaddr()
  (CVE-2024-27417 bsc#1224721)
- commit 9d4dafd

- af_unix: annote lockless accesses to unix_tot_inflight &amp;amp;
  gc_in_progress (bsc#1223384).
- Refresh
  patches.suse/io_uring-af_unix-defer-registered-files-gc-to-io_uri.patch.
- commit 478234c

- Update patch reference for media fix (CVE-2024-35830 bsc#1224680)
- commit aae637c

- regulator: bd71828: Don't overwrite runtime voltages
  (git-fixes).
- nfc: nci: Fix handling of zero-length payload packets in
  nci_rx_work() (git-fixes).
- nfc: nci: Fix uninit-value in nci_rx_work (git-fixes).
- tools/latency-collector: Fix -Wformat-security compile warns
  (git-fixes).
- commit 6c22f99

- bpf: Protect against int overflow for stack access size
  (bsc#1224488 CVE-2024-35905).
- bpf: Check bloom filter map value size (bsc#1224488
  CVE-2024-35905).
- commit c3a457f

- io_uring: drop any code related to SCM_RIGHTS (git-fixes
  CVE-2023-52656 bsc#1224187).
- io_uring/unix: drop usage of io_uring socket (git-fixes).
- commit 2c7c0cc

- autofs: use wake_up() instead of wake_up_interruptible(()
  (bsc#1224166).
- commit 63af67f

- Update patches.suse/io_uring-af_unix-disable-sending-io_uring-over-socke.patch
  (bsc#1218447 CVE-2023-6531 CVE-2023-52654 bsc#1224099)
  This commit was merged twice, through the net and io_uring maintainer
  trees. Add an Alt-commit entry to document that.
- commit 8d7b4ed

- Update patches.suse/scsi-qedf-Wait-for-stag-work-during-unload.patch (bsc#1214852)
- Update patches.suse/scsi-qedf-Don-t-process-stag-work-during-unload.patch (bsc#1214852)
- commit c7be571

- Update patches.suse/afs-Fix-page-leak.patch (stable-5.14.9
  CVE-2021-47365 bsc#1224895).
- commit c17c3b1

- Update
  patches.suse/afs-Fix-corruption-in-reads-at-fpos-2G-4G-from-an-Op.patch
  (stable-5.14.9 CVE-2021-47366 bsc#1225160).
- commit f8c347d

- s390/ipl: Fix incorrect initialization of len fields in nvme
  reipl block (git-fixes bsc#1225139).
- commit fa2a3c7

- s390/ipl: Fix incorrect initialization of nvme dump block
  (git-fixes bsc#1225138).
- commit 99842eb

- ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()
  (CVE-2023-52674 bsc#1224727).
- ALSA: scarlett2: Add missing error checks to *_ctl_get()
  (CVE-2023-52680 bsc#1224608).
- ALSA: scarlett2: Add missing error check to
  scarlett2_usb_set_config() (CVE-2023-52692 bsc#1224628).
- commit 76e573a

- spmi: hisi-spmi-controller: Do not override device identifier
  (git-fixes).
- extcon: max8997: select IRQ_DOMAIN instead of depending on it
  (git-fixes).
- vmci: prevent speculation leaks by sanitizing event in
  event_deliver() (git-fixes).
- VMCI: Fix an error handling path in vmci_guest_probe_device()
  (git-fixes).
- iio: pressure: dps310: support negative temperature values
  (git-fixes).
- iio: core: Leave private pointer NULL when no private data
  supplied (git-fixes).
- serial: sh-sci: protect invalidating RXDMA on shutdown
  (git-fixes).
- serial: sc16is7xx: add proper sched.h include for
  sched_set_fifo() (git-fixes).
- serial: max3100: Fix bitwise types (git-fixes).
- serial: max3100: Update uart_driver_registered on driver removal
  (git-fixes).
- serial: max3100: Lock port-&amp;gt;lock when calling
  uart_handle_cts_change() (git-fixes).
- usb: typec: tipd: fix event checking for tps6598x (git-fixes).
- usb: typec: ucsi: displayport: Fix potential deadlock
  (git-fixes).
- usb: gadget: u_audio: Clear uac pointer when freed (git-fixes).
- leds: pwm: Disable PWM when going to suspend (git-fixes).
- VMCI: Fix possible memcpy() run-time warning in
  vmci_datagram_invoke_guest_handler() (stable-fixes).
- VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()
  (stable-fixes CVE-2024-35944 bsc#1224648).
- spmi: Add a check for remove callback when removing a SPMI
  driver (git-fixes).
- commit d71c003

Package containerd was updated:

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

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

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

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

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

Package crmsh was updated:

- Update to version 4.5.1+20240719.bda4d1e:  * Dev: prun: add more possible libexec PATH for sftp-server
  * Fix: qdevice: config &amp;quot;tls&amp;quot; should accept value &amp;quot;required&amp;quot; (bsc#1227649)
  * Fix: bootstrap: refine the wording in the question asking TLS config for qdevice (bsc#1227649)
  * Fix: qdevice: TLS certs should always be generated for qnetd (bsc#1227649)
  * Fix: upgradeutil: refine error handling (bsc#1226147, bsc#1223371)

- Update to version 4.5.1+20240531.f62a43e:
  * Fix: cmd_status: call crm_mon without shell (#1429)
  * Dev: utils: Add info when property is newly added
  * Fix: healthcheck: KeyError when local nodename not found in cib (bsc#1223438)

Package cups was updated:

- Require the exact matching version-release of all libcups*  sub-packages (bsc#1226192)

- cups-2.2.7-CVE-2024-35235.patch is derived
  from the upstream patch against master (CUPS 2.5)
  to behave backward compatible for CUPS 2.2.7
  in SLE15 and openSUSE Leap 15 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

- cups-2.2.7-web-ui-kerberos-authentication.patch, update
  patch to handle local 'Negotiate' authentication response
  for cli clients. (bsc#1223179).

Package desktop-data-SLE was updated:

- Fix typo in the desktop files for some of the wallpapers  (bsc#1222146).

Package docker was updated:

[NOTE: This update was only ever released in SLES and Leap.]- Update to Docker 25.0.6-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/25.0/#2506&amp;gt;
- This update includes a fix for CVE-2024-41110. bsc#1228324
- Rebase patches:
  * 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  * 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch
  * 0006-bsc1221916-update-to-patched-buildkit-version-to-fix.patch
  * 0007-bsc1214855-volume-use-AtomicWriteFile-to-save-volume.patch

- Rebase patches:
  * 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  * 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch
- Fix BuildKit's symlink resolution logic to correctly handle non-lexical
  symlinks. Backport of &amp;lt;https://github.com/moby/buildkit/pull/4896&amp;gt; and
  &amp;lt;https://github.com/moby/buildkit/pull/5060&amp;gt;. bsc#1221916
  + 0006-bsc1221916-update-to-patched-buildkit-version-to-fix.patch
- Write volume options atomically so sudden system crashes won't result in
  future Docker starts failing due to empty files. Backport of
  &amp;lt;https://github.com/moby/moby/pull/48034&amp;gt;. bsc#1214855
  + 0007-bsc1214855-volume-use-AtomicWriteFile-to-save-volume.patch

[NOTE: This update was only ever released in SLES and Leap.]
- Update to Docker 25.0.5-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/25.0/#2505&amp;gt; bsc#1223409
- Rebase patches:
  * 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch
  * 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch
  * 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch
  * 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch
  * 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch
  * cli-0001-docs-include-required-tools-in-source-tree.patch
- Remove upstreamed patches:
  - 0007-daemon-overlay2-remove-world-writable-permission-fro.patch
- Update --add-runtime to point to correct binary path.

Package dracut was updated:

- Update to version 055+suse.388.g70c21afa:  * feat(crypt): force the inclusion of crypttab entries with x-initrd.attach (bsc#1226529)
  * fix(mdraid): try to assemble the missing raid device (bsc#1226412)
  * fix(dracut-install): continue parsing if ldd prints &amp;quot;cannot be preloaded&amp;quot; (bsc#1208690)

Package fdupes was updated:

- Do not use sqlite, as this pulls sqlite into Ring0 at no real  benefit performance wise: the cache is not reused between runs.
  + Drop sqlite-devel BuildRequires
  + Pass --without-sqlite to configure

- Update to 2.3.0:
  * Add --cache option to speed up file comparisons.
  * Use nanosecond precision for file times, if available.
  * Fix compilation issue on OpenBSD.
  * Other changes like fixing typos, wording, etc.

- update to 2.2.1:
  * Fix bug in code meant to skip over the current log file when --log option is given.
  * Updates to copyright notices in source code.
  * Add --deferconfirmation option.
  * Check that files marked as duplicates haven't changed during program execution before deleting them.
  * Update documentation to indicate units for SIZE in command-line options.
  * Move some configuration settings to configure.ac file.

- Fixes for the new wrapper:
  * Order duplicates by name, to get a reproducible file set
    (boo#1197484).
  * Remove redundant order parameter from fdupes invocation.
  * Modernize code, significantly reduce allocations.
  * Exit immediately when mandatory parameters are missing.
  * Remove obsolete buildroot parameter
  * Add some tests for the wrapper

- A more correct approach to creating symlinks (old bug actually):
  Do not link the files as given by fdupes, but turn them into
  relative links (it works by chance if given a buildroot, but
  fails if running on a subdirectory)
- Support multiple directories given (as glob to the macro)

- Handle symlinks (-s argument) correctly

- Simplify macros.fdupes with a call to a C++ program that does
  the same within a fraction of a second what the shell loop did
  in many seconds (bsc#1195709)

Package gdk-pixbuf was updated:

- Enable test suite on x86_64 (other arches seem too flaky for now):  + Add %check section and call %meson_test
  + Add gdk-pixbuf-jpeg-slow.patch: allow pixbuf-jpeg to run for
    more than 30s, by marking it as a slow test
    (glgo#GNOME/gdk-pixbuf!174).

- Migrate package to a regular obs_scm service, no longer password
  protecting a zip file. The originally reported bsc#1159337 seems
  no longer be applicable and we prefer the easier route.
- Drop unzip BuildRequires and pre_checkin.sh script.

- Update to version 2.42.12:
  + Fix a build failure,
  + Fix occasional build failures,
  + ani: Reject files with multiple INA or IART chunks,
  + ani: Reject files with multiple anih chunks (CVE-2022-48622),
  + ani: validate chunk size,
  + Updated translations.
- Drop 238893d8cd6f9c2616a05ab521a29651a17a38c2.patch: fixed
  upstream.

- Pass -Dothers=enabled to meson: enable other image loaders (most
  notably beeded seems xpm,xbm). This is in line with upstreams
  recommendation for now, but won't be working past version 2.43.x.
  The loaders will likely be split out into a separate repo.
  (boo#1223903, glgo#GNOME/gdk-pixbuf!169).
- Add 238893d8cd6f9c2616a05ab521a29651a17a38c2.patch: Fix test
  suite with other loaders enabled.

- Update to version 2.42.11:
  + Disable fringe loaders by default.
  + Introspection fixes.
  + Updated translations.

- Fix path to gdk-pixbuf-query-loader in pkg-config file: we rename
  the loader to be multi-arch compatible and thus also need to
  adjust the .pc file to have build-systems find it.

- Update to version 2.42.10:
  + Search for rst2man.py.
  + Update the memory size limit for JPEG images.
  + Updated translations.
- Drop patch fixed upstream (with different limit):
  + 0001-jpeg-Increase-memory-limit-for-loading-image-data.patch

Package glib2 was updated:

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

Package glibc was updated:

- nscd-netgroup-cache-timeout.patch: Use time_t for return type of  addgetnetgrentX (CVE-2024-33602, bsc#1223425)

- ulp-prologue-into-asm-functions.patch: Avoid creating ULP prologue
  for _start routine (bsc#1221940)

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

Package google-cloud-sap-agent was updated:

- Update to version 3.4 (bsc#1227134, bsc#1227135)  * Adding project to exclusion list
  * Add machine type to configure instance proto for WLM metric collection.
  * Add test channel for Guest Actions. Make default channel the registered channel.
  * Set backup object's customTime field as part of backint backups
  * Add workload discovery to configure command
  * Add multiple workers support in parallelreader for parallel downloading during restore.
  * `configureinstance` with `overrideVersion` set should log a warning and continue.
  * Minor log change in balanceirq
  * Add common function to parse parameters for guest action handlers
  * BalanceIRQ OTE added to Agent for SAP
  * Remove output from stdout for DIAGNOSE
  * Small hyperThreading change for configureinstance
  * Add initial steps to initialize the SystemDiscovery OTE in IIOTE and command mode.
  * Adding single worker support in parallelreader for download.
  * Read encryption key from file if specified in parameters file
  * Run configureinstance OTE only on supported instances during WLM metric collection.
  * Add instance ID to user agent string for SAP Agent.
  * Return `UsageError` as exit status instead of `Failure` in case of invalid parameters
  * Bumping up the agent version
  * Use json marshalling instead of manually parsing from map in configure handler
  * Move metric override modules to metricoverrides.go for general use
  * Updating the gcbdr proto
  * Updating param names to make it more clear in performance diagnostics
  * Add DiskSizeGb to Disk for disk creation.
  * Add Demo Metrics for Process Metrics
  * Add warning message for configureinstance overrideVersion
  * Add 3.3 to configureinstance versioning
  * Fix log message in configureinstance
  * Rename scope and param file to type and backint-param-file to avoid confusion
  * Add new OTE structure for SystemDiscovery.
  * Allows SAP system data to be read from an override file instead
    of discovered from the system. Useful for testing.
  * Refactor buildSupportBundleCommand by marshalling command parameters
  * Remove cluster member check for cluster collection
  * Add connectParameters as a function parameter in restoreFile function to have
    multiple bucket handles in parallelreader for parallel downloading.
  * Enable auto discovery of disks and make datadiskname and zone optional parameters
  * Add support for performancediagnostics OTE guest action handler
  * Add override version flag to configureinstance
  * Rename LVM volume group of restored disk to that of the target disk.
  * Sleep during TestCommunicateWithUAP to only execute intended
    code path once instead of many times.
  * Update grub configuration for X4 configureinstance
  * Extend result-bucket support to support bundle guest action
  * Add provisioned-iops and provisioned-throughput labels
    to snapshots and extract them during restore.
  * Configureinstance updates for SAP ECS
  * Add sequential in parallel download functionality for restore to SAP Agent.
  * Implement hanadiskbackup guest action handler
  * Add operation_id to UAP status labels.
  * Add user agent overrides for cloud monitoring
  * Updating generated protobufs
  * Update sanity check for fast collector metric
  * Reliability Metrics - Use the usage metrics instead of
    internal cloud monitoring metrics
  * Fix restoreFromGroupSnapshot and restoreFromSingleSnapshot logic
  * Implement support bundle handler. This CL follows a pattern for
    implementing handler which was developed in cl/636640791
  * Move timeseries.go and cloudmonitoring.go to shared/
  * Only stop HANA monitoring if successive errors are auth related
  * Use flag names for command parameters in configureHandler
  * Add check and apply finished metrics to configureinstance
  * Add snapshot / group backup name to success log message
  * Better handling of experimental flag in hanamonitoring
  * Return error if physical device is empty
  * Added an experiemntal flag to control role based awareness in hana monitoring
  * Adding role based awareness logic in HANA Monitoring
  * Add upload feature to support bundle
  * Add context to onetime logging functions
  * Fix logging and make confirm-data-snapshot-after-create true by default
  * Add debug logs for hanabackup to help troubleshoot issues.
  * Remove HDB User requirement when HDBUserstore key is passed for hanadiskbackup
  * Append labels to detached disk in hanadiskrestore
  * Add placeholder for parallel reader in Backint
  * Modify restore handlers to be able to restore from either
    source snapshot or group snapshot.
  * Modify checking preconditions and adding fakes for group snapshot restore.
  * Add initial support for restoring from group snapshot.
  * Add UAP Communication to startdaemon (gated by a configuration).
  * Fixing the commands in perfdiag
  * Refactor handleAgentCommand with guestActionsHandlers map
  * Add replication sites to system component proto
  * Build updated to use -mod=vendor during build
  * Updated go.mod and go.sum with dependencies for safetext,
    using go mod vendor for github action
  * Adding changes for target based config in hana monitoring
  * Overriding the user agent for Cloud Logging API calls
  * Fix typo in guestactions.proto
  * WLM Hana Full Backup Validation Metric collection
  * Add configure command to guest actions. Establish how the new proto
    format will be used in message handling.
  * Add ping check to HANA monitoring
  * [commandlineexecutor] Add the ability to directly pass data into Stdin, avoiding
    the need for intermediary piping commands, such as &amp;quot;echo 'data' | my_app&amp;quot;.

- Update to version 3.3 (bsc#1225166, bsc#1225558)
  * Build updated to use -mod=vendor during build
  * Updated go.mod and go.sum with dependencies for safetext,
    using go mod vendor for github action
  * Add actual values and comments to usagemetrics.go to ensure that
    error and action codes are only appended to the end of the list.
  * Remove usage metrics from configureinstance.go
  * Add a hard Disable for reliability metrics collection
    until the namespace is created and tested.
  * Adding metrics for time taken by each query
  * Add SHA224 of labels as a new label.
  * Remove collect_reliability_metrics from configuration.json
  * Small tweaks to backint log and inquire path generation
  * Fix for unmarshalling backint configuration.
  * Implementation of instant snapshot group backup workflow
  * Backint changes around shorten_folder_path
  * Rename max_diagnose_size_gb to diagnose_file_max_size_gb
  * Adding start and finish logs in performance diagnostics
  * Validate that all disks mapped to /hana/data belong to the same consistency group.
  * Rename backint monitoring metrics parameter
  * Trim folder prefix for Backint INQUIRE output.
  * Add the ability to test the database connection
  * Reduce log level of some storage messages to debug.
  * Finalize guest action request and response format.
  * Backint dashboard fix logs
  * Add scorecards to backint dashboard
  * Making proto changes for HANA Monitoring support
    for multiple tennats and ha setup
  * Add total upload/download time to log.
  * Add HANA indexserver.ini metrics to WLM metric collection.
  * Add Netweaver role metrics as part of process metrics
  * Rotate old support bundles.
  * Update the default value of confirm-data-snapshot-after-create
    to false. and add to usage()
  * Add option to confirm HANA snapshot as successful before disk snapshot is uploaded.
  * Change log level from warn to info for non-critical messages.
  * Add diagnose_folder parameter to Backint
  * Add a 1 GB buffer to needed bytes for diagnostic
  * Add labels to group snapshot backup.
  * Enable the show status and restart agent functions for Windows.
  * Add WLM metric collection for num_completion_queues and num_submit_queues.
  * Collect support bundle on Backint errors.
  * Adding usage metrics to performance diagnostics
  * Collect agent-only support bundle on failure of backint and hanadiskbackup.
  * Minor Backint improvements
  * Add ability collect only agent logs using agent-logs-only flag to supportbundle
  * Bump version to 3.3
  * Add Backint metrics dashboard
  * DO NOT remove log files on uninstall
  * Adding more unit tests
  * Changing location of zipped file to within the
    final folder identified by unique timestamp.
  * Minor refactorings and improvements with increasing code coverage
  * Make sure DB instance number is recorded in System data.
  * Change configuration.json to 0664 to ensure world cannot write.
  * Add Netweaver Java discovery to SAP Agent.
  * Add a new version of functions to read cloud properties from metadata server.
  * Updating generated protos to proc-gen-go v1.34.1
  * Updating runConfigureInstance method and adding unit tests
    for covering configure instance ote invocation
  * Zip the final bundle and add upload functionality
  * Record database SID alongside tenant DB SIDs
  * Reduce log severity in discovery
  * Add HANA version to product version data
  * Fix race condition in tests
  * Read disk mapping from instance info if source disk
    is not provided to hanadiskbackup
  * Add option to shorten the folder path in the bucket.
  * Add SSL support for cmdline-based querying and some bugfixes
  * Move recovery package to shared directory.
  * Update protoc-gen-go version to v1.34.0 in multiple protos
  * Adding FIO commands to performance diagnostics
  * Remove error logs when errors are being returned
  * Adding perfdiag to performance diagnostics
  * Add AppInstance data to discovery data uploads.
  * Introduce protos for guestactions messages and responses.
    Support multiple commands per message.
  * Update wording for HANA Insights rules.
  * Configureinstance updates.
  * Adding a check for retention policy before performing backup operation.
  * Remove the unused loglevel flag from logusage OTE
  * Change the language around the default parameters being
    optimized for performance in backint
  * Add instance role to SAP System properties
  * Increase wait time for index server to stop.
  * Integrating backint OTE into performancediagnostics
  * Update wording around configureinstance unsupported machine type.
  * Pass the right disk name to check if disk is attached
  * Integrating new DB Handle and hdbuserstore key support
    with remaining HANA DB dependant workflows
  * Refactor HANA and filesystems specific code to a common hanabackup package
  * Bumps x/net dependency to v0.23
  * Append HANA Insights rule to WLM fake metrics file in script to generate WLM rule.
  * Integrating configure instance ote in performance diagnostics
  * Update disk backup OTE to parse paths even with /dev/mapper
    in the middle of path, not necessarily as a prefix
  * Adding a few missing labels to wlm-fake-metrics.yaml
  * Changing loglevel for onetime.Init() calls
  * Refactor change - Move PD related functions to gce.go
  * Fix agentcommunication import replace statements
  * Update replace functions for new open source dependencies.
  * Set up scaffolding for guest actions handling in SAP Agent along with UAP library code
  * Backint upload/download metrics sent to cloud monitoring.
  * Cleaning up the performance diagntics file wth recent changes
  * Fixes to usage strings in OTEs for optional params
  * Integrating new database connector with HANA Monitoring
    and adding support for HDBUserstore Key
  * Implement hdbsql commandline result parsing
  * SAP Discovery - Add SAP Instance Numbers to instance properties
  * Updating OTEs to include params for when OTE is invoked internally
  * Modifying flags to follow design changes
  * Create fake WLM metric overrides for testing
  * Implement constructors and query functions for querying
    HANA DB via hdbuserstore using cmdline
  * Skeleton for querying HANA DB via hdbuserstore using cmdline
  * Parameterize Backint Diagnose max file size.
  * Metadata parameter added to Backint.
  * Adding initial layout for performance diagnostics OTE
  * Create a new API CreateClient() in shared logging which
    returns an error in case of failures
  * Backint no longer writes ERROR if temporary chunk failed to delete.
  * Create onetime.Init() to condense reused code.
  * Fixing a typo in a process metrics retry logic comment
  * Rename workload_validation param with workload_evaluation in configure OTE
  * Send agent version in Write Insight requests
  * Ensuring /sap/cluster/resources covers all the nodes.

Package gtk2 was updated:

- Add CVE-2024-6655.patch: CVE-2024-6655 Stop looking for modules  in cwd (bsc#1228120).

Package iputils was updated:

- Update 0002-arping-Fix-unsolicited-ARP-regressions-on-c-1.patch  after upstream merged the fix, update git commit hashes.

- Backport proposed fix for regression in upstream commit 4db1de6 (bsc#1224877)
  0002-arping-Fix-unsolicited-ARP-regressions-on-c-1.patch

- Backport upstream fix for bsc#1224877
  4db1de6 (&amp;quot;arping: Fix 1s delay on exit for unsolicited arpings&amp;quot;)
  0001-arping-Fix-1s-delay-on-exit-for-unsolicited-arpings.patch

Package krb5 was updated:

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

Package resource-agents was updated:

- Azure-lb fails if IPv6 disabled (bsc#1223554)  Add upstream patch
    Add a new parameter: listen
    This parameter can have following walues:
    default: Neither -4 nor -6 will be used. The default behavior of socat and nc will be used.
    socat: Listen only on IPv4 addresses
    nc: If net.ipv6.bindv6only = 0 =&amp;gt; Listen on both IPv4 and IP6 addresses
    If net.ipv6.bindv6only = 1 =&amp;gt; Listen only on IPv4 addresses
    ipv4only: Listen only on IPv4 addresses.
    ipv6enable: Enable TCP6 support.
    nc: Listen only on IPv6 adresses independent of net.ipv6.bindv6only
    socat: If net.ipv6.bindv6only = 0 =&amp;gt; Listen on both IPv4 and IP6 addresses.
    If net.ipv6.bindv6only = 1 =&amp;gt; Listen only on IPv6 adresses.
  Add patch:
    0001-Azure-lb-fails-if-IPv6-disabled.patch

Package llvm15 was updated:

- Manage clang-cpp with update-alternatives like other binaries.  Solves upgrade issues from Leap 15.5 to 15.6.  [boo#1221183]

Package libqt5-qtbase was updated:

- Add patch from upstream to fix a regression in the ODBC driver  (bsc#1227513, QTBUG-112375):
  * 0001-QSQL-ODBC-fix-regression-trailing-NUL.patch
  * 0002-SQL-ODBC-Pass-correct-length-to-SQLColAttribute.patch

Package abseil-cpp was updated:

- SLE-only: import upstream patch to fix build with gcc7 in C++17  mode: hash-fix-gcc7-cpp17-build.patch (bsc#1222261)
  + Upstream commit bb83aceacb554e79e7cd2404856f0be30bd00303

- update to 20240116.1:
  * Add absl::NoDestructor&amp;lt;T&amp;gt; to simplify defining static types
    that do not need to be destructed upon program exit.
  * Add configurable verbose logging (also known as VLOG).
  * Added absl::Overload(), which returns a functor that provides
    overloads based on the functors passed to it. Note that this
    functionality requires C++17 or newer.
  * Breaking Change: AbslHashValue() no longer accepts C-style
    arrays as a parameter, caller need to wrap C-string literals in
    absl::string_view.
  * Breaking Change: absl::weak_equality and absl::strong_equality
    have been removed. The corresponding std types were removed
    before C++20 was finalized

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.

Package util-linux was updated:

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

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

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

Package mozilla-nss was updated:

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

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

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

- Fix a stack corruption on s390x: [bsc#1209627]  * Output size of the STCKE command on s390x is 16 bytes, compared
    to 8 bytes of the STCK command. Fix a stack corruption in the
    s390x version of jent_get_nstime(). Add some more detailed
    information on the STCKE command.
  * github.com/smuellerDD/jitterentropy-library/commit/7bf9f85
  * Add jitterentropy-fix-a-stack-corruption-on-s390x.patch

Package oniguruma was updated:

- Added oniguruma-6.8.2-CVE-2019-13225-fix.patch (boo#1141157 CVE-2019-13225)  oniguruma: null-pointer dereference in match_at() in regexec.c

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]

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

Package libqb was updated:

- ipc: Retry receiving credentials if the the message is short (gh#ClusterLabs/libqb#476, rh#2111711, bsc#1224183)  * bsc#1224183-0001-ipc-Retry-receiving-credentials-if-the-the-message-i.patch

Package libsolv was updated:

- add a conflict to older libsolv-tools to libsolv-tools-base
- improve updating of installed multiversion packages
- fix decision introspection going into an endless loop in some
  cases
- added experimental lua bindings
- bump version to 0.7.29

- split libsolv-tools into libsolv-tools-base [jsc#PED-8153]

Package suseconnect-ng was updated:

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

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

Package tiff was updated:

- security update:  * CVE-2023-3164 [bsc#1212233]
    Fix heap buffer overflow in tiffcrop
    + tiff-CVE-2023-3164.patch

Package libvirt was updated:

- rpc: Don't warn about &amp;quot;max_client_requests&amp;quot; in single-threaded  daemons
  boo#1224327

- security: Ensure file exists before attempting to restore label
  bsc#1220714

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

- zypp-tui: Make sure translated texts use the correct textdomain  (fixes #551)
- Skip libproxy1 requires for tumbleweed.
- version 17.34.1 (34)

- don't require libproxy1 on tumbleweed, it is optional now

- version 17.34.0 (34)
- Fix versioning scheme

- version 17.33.4 (35)

- add one more missing export for libyui-qt-pkg

- Revert eintrSafeCall behavior to setting errno to 0.
- version 17.33.3 (34)

- fix up requires_eq usage for libsolv-tools-base
- add one more missing export for PackageKit
- version 17.33.2

- version 17.33.1 (33)

- switch to reduced size libsolv-tools-base (jsc#PED-8153)

- Fixed check for outdated repo metadata as non-root user
  (bsc#1222086)
- Add ZYPP_API for exported functions and switch to
  visibility=hidden (jsc#PED-8153)
- Dynamically resolve libproxy (jsc#PED-8153)
- version 17.33.0 (33)

- Fix download from gpgkey URL (bsc#1223430, fixes openSUSE/zypper#546)
- version 17.32.6 (32)

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

- Added data for 5_14_21-150400_24_119,  5_14_21-150400_24_122, 5_14_21-150500_55_62,
  5_14_21-150500_55_65, 5_14_21-150500_55_68,
  5_3_18-150200_24_191, 5_3_18-150200_24_194,
  5_3_18-150300_59_161, 5_3_18-150300_59_164,
  6_4_0-150600_21, 6_4_0-150600_23_7,
  +kernel-livepatch-5_14_21-150500_13_52-rt,*,+kernel-livepatch-5_14_21-150500_13_55-rt,*,+kernel-livepatch-5_14_21-150500_13_58-rt,*. (bsc#1020320)

- Added data for 5_14_21-150400_24_111, 5_14_21-150400_24_116,
  5_14_21-150500_55_52, 5_14_21-150500_55_59,
  5_3_18-150200_24_183, 5_3_18-150200_24_188,
  5_3_18-150300_59_153, 5_3_18-150300_59_158,
  +kernel-livepatch-5_14_21-150400_15_71-rt,*,+kernel-livepatch-5_14_21-150500_13_38-rt,*,+kernel-livepatch-5_14_21-150500_13_43-rt,*,+kernel-livepatch-5_14_21-150500_13_47-rt,*. (bsc#1020320)

Package shadow was updated:

- bsc#1228770: Fix not copying of skel files  Update shadow-CVE-2013-4235.patch

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

Package ocfs2-tools was updated:

- OCFS2 writes delay on large volumes - slow la window lookup from global_bitmap (bsc#1219224)  * bsc1219224-debugfs.ocfs2-support-recording-gd-bg_contig_free_bi.patch

Package pacemaker was updated:

- tools: CIB clients retry signon upon an EAGAIN error (gh#ClusterLabs/pacemaker#3567, bsc#1224183)  * bsc#1224183-0002-Fix-tools-CIB-clients-retry-signon-upon-an-EAGAIN-er.patch
- libcib: new function cib__signon_attempts() (gh#ClusterLabs/pacemaker#3567, bsc#1224183)
  * bsc#1224183-0001-Refactor-libcib-new-function-cib__signon_attempts.patch

- libcrmcommon: reject ISO 8601 duration without any values (gh#ClusterLabs/pacemaker#3517)
  * pacemaker#3517-0002-Low-libcrmcommon-reject-ISO-8601-duration-without-an.patch
- libstonithd: prevent to free 'op_reply' repeatedly in 'stonith_send_command' (gh#ClusterLabs/pacemaker#3517)
  * pacemaker#3517-0001-prevent-to-free-op_reply-repeatedly-in-stonith_send_.patch

- libpacemaker: correctly retrieve any existing fail-count for increment (gh#ClusterLabs/pacemaker#3513)
  * pacemaker#3513-0001-Fix-libpacemaker-correctly-retrieve-any-existing-fai.patch

- tools: make crm_mon exit upon loss of the attached pseudo-terminal (bsc#1220229, gh#ClusterLabs/pacemaker#3430)
  * bsc#1220229-0001-Fix-tools-make-crm_mon-exit-upon-loss-of-the-attache.patch

- libcib: Don't incorrectly expand &amp;quot;++&amp;quot; and &amp;quot;+=&amp;quot; in XML attr values (gh#ClusterLabs/pacemaker#3413)
  * pacemaker#3413-0003-Fix-libcib-Don-t-incorrectly-expand-and-in-XML-attr-.patch
- cts-cli: Update for pcmk__inject_failcount() setting integer value (gh#ClusterLabs/pacemaker#3413)
  * pacemaker#3413-0002-Test-cts-cli-Update-for-pcmk__inject_failcount-setti.patch
- libpacemaker: pcmk__inject_failcount should set an integer value (gh#ClusterLabs/pacemaker#3413)
  * pacemaker#3413-0001-Low-libpacemaker-pcmk__inject_failcount-should-set-a.patch
- scheduler: log unknown nodes in location constraints (gh#ClusterLabs/pacemaker#3409, CLBZ#5415)
  * pacemaker#3409-0007-Log-scheduler-log-unknown-nodes-in-location-constrai.patch
- scheduler: correct lifetime deprecation warning (gh#ClusterLabs/pacemaker#3409)
  * pacemaker#3409-0006-Log-scheduler-correct-lifetime-deprecation-warning.patch
- tools: honor rules when getting utilization attributes with crm_resource (gh#ClusterLabs/pacemaker#3409)
  * pacemaker#3409-0005-Fix-tools-honor-rules-when-getting-utilization-attri.patch
- scheduler: deprecate support for default instance attributes (gh#ClusterLabs/pacemaker#3409)
  * pacemaker#3409-0004-Low-scheduler-deprecate-support-for-default-instance.patch
- scheduler: use default timeout (20s) if user configures 0 (gh#ClusterLabs/pacemaker#3409)
  * pacemaker#3409-0003-Fix-scheduler-use-default-timeout-20s-if-user-config.patch
- tools: crm_resource should ignore resource meta-attribute node expressions (gh#ClusterLabs/pacemaker#3409)
  * pacemaker#3409-0001-Fix-tools-crm_resource-should-ignore-resource-meta-a.patch

- fencer: always format time_t values as long long (gh#ClusterLabs/pacemaker#3407)
  * pacemaker#3407-0001-Log-fencer-always-format-time_t-values-as-long-long.patch

- libcrmcommon: NULL-check strdup() in pcmk__register_message() (gh#ClusterLabs/pacemaker#3394)
  * pacemaker#3394-0004-Low-libcrmcommon-NULL-check-strdup-in-pcmk__register.patch
- libcrmcommon: NULL-check strdup() in pcmk__register_format() (gh#ClusterLabs/pacemaker#3394)
  * pacemaker#3394-0003-Low-libcrmcommon-NULL-check-strdup-in-pcmk__register.patch
- libpacemaker: Correctly free graphs and synapses (gh#ClusterLabs/pacemaker#3394)
  * pacemaker#3394-0002-Low-libpacemaker-Correctly-free-graphs-and-synapses.patch
- libcrmcommon: Initialize some variables (gh#ClusterLabs/pacemaker#3394)
  * pacemaker#3394-0001-Low-libcrmcommon-Initialize-some-variables.patch
- HealthSMART:fix the description of temp_lower_limit (gh#ClusterLabs/pacemaker#3392)
  * pacemaker#3392-0001-Doc-HealthSMART-fix-the-description-of-temp_lower_li.patch

- cibsecret: Use 'ps axww' to avoid truncating issue (gh#ClusterLabs/pacemaker#3384)
  * pacemaker#3384-0001-Fix-cibsecret-Use-ps-axww-to-avoid-truncating-issue.patch

- libcrmcommon: Don't try to parse XML from bad .bz2 file (gh#ClusterLabs/pacemaker#3361)
  * pacemaker#3361-0001-Low-libcrmcommon-Don-t-try-to-parse-XML-from-bad-.bz.patch

- libcrmcommon: use uint32_t for 32-bit magic numbers (gh#ClusterLabs/pacemaker#3381)
  * pacemaker#3381-0001-Fix-libcrmcommon-use-uint32_t-for-32-bit-magic-numbe.patch

- libcrmcommon: Use free_xml in html_free_priv. (gh#ClusterLabs/pacemaker#3380)
  * pacemaker#3380-0003-Low-libcrmcommon-Use-free_xml-in-html_free_priv.patch
- libcrmcommon:  Free error strings in html/xml outputters. (gh#ClusterLabs/pacemaker#3380)
  * pacemaker#3380-0002-Low-libcrmcommon-Free-error-strings-in-html-xml-outp.patch
- libcrmcommon: Free text/curses private list data. (gh#ClusterLabs/pacemaker#3380)
  * pacemaker#3380-0001-Low-libcrmcommon-Free-text-curses-private-list-data.patch
- tools: Fix argument validation for crm_attribute update. (gh#ClusterLabs/pacemaker#3379)
  * pacemaker#3379-0001-Low-tools-Fix-argument-validation-for-crm_attribute-.patch

Package patterns-base was updated:

- Added a fips-certified pattern matching the exact certified  FIPS versions

Package python3-lxml was updated:

- Add libexpat-2.6.0-backport.patch to fix compatibility with system  libexpat in tests (bsc#1222075, CVE-2023-52425).

Package python-requests was updated:

- Update CVE-2024-35195.patch to allow the usage of &amp;quot;verify&amp;quot; parameter  as a directory, bsc#1225912

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

Package python-urllib3 was updated:

Package rubygem-sass was updated:

- updated to version 3.7.4  no changelog found

- updated to version 3.7.3
  no changelog found

- updated to version 3.7.2
  no changelog found

- updated to version 3.6.0
  no changelog found

- updated to version 3.5.7
  no changelog found

- updated to version 3.5.6
  no changelog found

- updated to version 3.5.5
  no changelog found

Package runc was updated:

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

Package scap-security-guide was updated:

- updated to 0.1.73 (jsc#ECO-3319)  - CMP 2417: Implement PCI-DSS v4.0 outline for OpenShift (#11651)
  - Update all RHEL ANSSI BP028 profiles to be aligned with configuration recommendations version 2.0
  - Generate rule references from control files (#11540)
  - Initial implementation of STIG V1R1 profile for Ubuntu 22.04 LTS (#11820)

- updated to 0.1.72 (jsc#ECO-3319)
  - ANSSI BP 028 profile for debian12 (#11368)
  - Building on Windows (#11406)
  - Control for BSI APP.4.4 (#11342)
  - update to CIS RHEL 7 and RHEL 8 profiles aligning them with the latest benchmarks
  - various fixes to SLE profiles
- add openeuler to -redhat package
- removed ssg-fix-journald.patch: fixed upstream

Package 000release-packages:sle-ha-release was updated:

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

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

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

Package 000release-packages:sle-module-development-tools-release was updated:

Package 000release-packages:sle-module-live-patching-release was updated:

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

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

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

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

Package 000release-packages:sle-module-web-scripting-release was updated:

Package socat was updated:

- Update to 1.8.0.0:  * Support for network namespaces (option netns)
  * TCP client now automatically tries all addresses (IPv4 and IPv6) provided by nameserver until success
  * Implementation of POSIX message queue (mq) control and access on Linux (addresses POSIXMQ-READ and following)
  * New wrapper script socat-chain.sh allows to stack two addresses, e.g.HTTP proxy connect over SSL
  * New script socat-mux.sh allows n-to-1 / 1-to-n communications
  * New script socat-broker.sh allows group communications
  * Experimental socks5 client feature
  * Address ACCEPT-FD for systemd &amp;quot;inetd&amp;quot; mode
  * UDP-Lite and DCCP address types
  * Addresses SOCKETPAIR and SHELL
  * New option bind-tmpname allows forked off children to bind UNIX domain client sockets to random unique pathes
  * New option retrieve-vlan (with INTERFACE addresses) now makes kernel keep VLAN tags in incoming packets
  * Simple statistics output with Socat option --statistics and with SIGUSR1
  * A couple of new options, many fixes and corrections, see file CHANGES
- Drop socat-common-fixes.patch (no longer necessary)
- Refactor socat-ignore-tests-failure-boo1078346.patch (test suite no longer exits at this stage)
- Add socat-test-dhparam fixture (reduce build load and time)
- Add socat-test-without-tty.patch for testing without tty.
- Note: This version introduces &amp;quot;socat1&amp;quot;, linking to &amp;quot;socat&amp;quot;
- Note: This version introduces additional shell scripts, those are shipped in a new &amp;quot;socat-extra&amp;quot; subpackage

- Update to 1.7.4.4:
  * FIX: InÂ error.cÂ msg2()Â thereÂ wasÂ aÂ stackÂ overflowÂ onÂ longÂ messages:Â The
    terminatingÂ \0Â ByteÂ wasÂ writtenÂ behindÂ theÂ lastÂ position.
  * FIX: UDP-RECVFROMÂ withÂ forkÂ sometimesÂ terminatedÂ whenÂ multipleÂ packets
    arrived.
  * FIX:Â aÂ coupleÂ ofÂ weaknessesÂ andÂ errorsÂ whenÂ accessingÂ invalidÂ or
  Â incompatibleÂ fileÂ systemÂ entriesÂ withÂ UNIXÂ domain,Â file,Â andÂ generic
    addresses.
  * FIX:Â badÂ parserÂ errorÂ messageÂ onÂ &amp;quot;socatÂ /tmp/x\&amp;quot;x/xÂ -&amp;quot;
- Drop socat-fix-asan-error.patch

- Use autosetup
- Add socat-fix-asan-error.patch that is offered to upstream
  and that fixes an ASAN error seen for 'test 313 NESTEDOVFL'.

- update to 1.7.4.3:
  * fixes the TCP_INFO issue that broke building on non-Linux platforms.
  * building on AIX works again.
  * A few more corrections and improvements have been added

- Update to version 1.7.4.2:
  * Fixes a lot of bugs, e.g., for options -r and -R.
  * Further bugfixes, see the CHANGES file

- update to 1.7.4.1:
  Security:
  * Buffer size option (-b) is internally doubled for CR-CRLF conversion,
    but not checked for integer overflow. This could lead to heap based buffer
    overflow, assuming the attacker could provide this parameter.
  * Many further bugfixes and new features, see the CHANGES file

- Update to version 1.7.3.4:
  * bugfix release, see the CHANGES file for all changes
- Refresh patches:
  * socat-common-fixes.patch
  * socat-ignore-tests-failure-boo1078346.patch

- socat-common-fixes.patch: include tcpd.h where needed to fix
  - fno-common bsc#1160293

- Update to version 1.7.3.3:
  * bugfix release, see the CHANGES file for all changes
- Drop patch:
  * socat-openssl-1.1-tests.patch (not longer needed)
- Run spec-cleaner

- Replace old variables by modern counterparts.

- We HAVE_SSLv23_*_method, just not as functions, but macros
  add the relevant defines in the command line so support for
  autonegotiation of the highest TLS version is restored.

Package supportutils was updated:

- Changes in version 3.1.30  + Added -V key:value pair option (bsc#1222021, PED-8211)
  + Avoid getting duplicate kernel verifications in boot.text (pr#193)
  + Suppress file descriptor leak warnings from lvm commands (pr#192, bsc#1220082)
  + Includes container log timestamps (pr#197)

Package suse-build-key was updated:

- added missing ; in shell script (bsc#1227681)
- Added new keys of the SLE Micro 6.0 / SLES 16 series, and auto import
  them. (bsc#1227429)
  gpg-pubkey-09d9ea69-645b99ce.asc: Main SLE Micro 6/SLES 16 key
  gpg-pubkey-73f03759-626bd414.asc: Backup SLE Micro 6/SLES 16 key.

Package suse-module-tools was updated:

- Update to version 15.5.5:  * Include unblacklist in initramfs (bsc#1224320)
  * regenerate-initrd-posttrans: run update-bootloader --refresh for XEN
  (bsc#1223278)
  * 60-io-scheduler.rules: test for &amp;quot;scheduler&amp;quot; sysfs attribute (boo#1216717)

Package util-linux-systemd was updated:

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

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

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

Package 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 wicked was updated:

- Update to version 0.6.76  - compat-suse: warn user and create missing parent config of
    infiniband children (gh#openSUSE/wicked#1027)
  - client: fix origin in loaded xml-config with obsolete port
    references but missing port interface config, causing a
    no-carrier of master (bsc#1226125)
  - ipv6: fix setup on ipv6.disable=1 kernel cmdline (bsc#1225976)
  - wireless: add frequency-list in station mode (jsc#PED-8715)
  - client: fix crash while hierarchy traversing due to loop in
    e.g. systemd-nspawn containers (bsc#1226664)
  - man: add supported bonding options to ifcfg-bonding(5) man page
    (gh#openSUSE/wicked#1021)
  - arputil: Document minimal interval for getopts (gh#openSUSE/wicked#1019)
  - man: (re)generate man pages from md sources (gh#openSUSE/wicked#1018)
  - client: warn on interface wait time reached (gh#openSUSE/wicked#1017)
  - compat-suse: fix dummy type detection from ifname to not cause
    conflicts with e.g. correct vlan config on dummy0.42 interfaces
    (gh#openSUSE/wicked#1016)
  - compat-suse: fix infiniband and infiniband child type detection
    from ifname (gh#openSUSE/wicked#1015)
- Removed patches included in the source archive:
  [- 0001-ifreload-pull-UP-again-on-master-lower-changes-bsc1224100.patch]
  [- 0002-increase-arp-retry-attempts-on-sending-bsc1218668.patch]

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

- bsc#1227355 - VUL-0: CVE-2024-31143: xen: double unlock in x86  guest IRQ handling (XSA-458)
  xsa458.patch

- bsc#1214718 - The system hangs intermittently when Power Control
  Mode is set to Minimum Power on SLES15SP5 Xen
  6666ba52-x86-irq-remove-offline-CPUs-from-old-CPU-mask-when.patch
  666994ab-x86-SMP-no-shorthand-IPI-in-hotplug.patch
  666994f0-x86-IRQ-limit-interrupt-movement-in-fixup_irqs.patch
  66718849-x86-IRQ-old_cpu_mask-in-fixup_irqs.patch
  6671885e-x86-IRQ-handle-moving-in-_assign_irq_vector.patch
  6673ffdc-x86-IRQ-forward-pending-to-new-dest-in-fixup_irqs.patch
- Upstream bug fixes (bsc#1027519)
  6646031f-x86-ucode-further-identify-already-up-to-date.patch
  666b07ee-x86-EPT-special-page-in-epte_get_entry_emt.patch
  666b0819-x86-EPT-avoid-marking-np-ents-for-reconfig.patch
  666b085a-x86-EPT-drop-questionable-mfn_valid-from-.patch
  667187cc-x86-Intel-unlock-CPUID-earlier.patch
  6672c846-x86-xstate-initialisation-of-XSS-cache.patch
  6672c847-x86-CPUID-XSAVE-dynamic-leaves.patch

- bsc#1221984 - VUL-0: CVE-2023-46842: xen: x86 HVM hypercalls may
  trigger Xen bug check (XSA-454)
  6617d62c-x86-hvm-Misra-Rule-19-1-regression.patch
- Upstream bug fixes (bsc#1027519)
  6627a4ee-vRTC-UIP-set-for-longer-than-expected.patch
  6627a5fc-x86-MTRR-inverted-WC-check.patch
  662a6a4c-x86-spec-reporting-of-BHB-clearing.patch
  662a6a8d-x86-spec-adjust-logic-to-elide-LFENCE.patch
  663090fd-x86-gen-cpuid-syntax.patch
  663a383c-libxs-open-xenbus-fds-as-O_CLOEXEC.patch
  663a4f3e-x86-cpu-policy-migration-IceLake-to-CascadeLake.patch
  663d05b5-x86-ucode-distinguish-up-to-date.patch
  663eaa27-libxl-XenStore-error-handling-in-device-creation.patch
  66450626-sched-set-all-sched_resource-data-inside-locked.patch
  66450627-x86-respect-mapcache_domain_init-failing.patch

Package xfsprogs was updated:

- xfs_copy: don't use cached buffer reads until after libxfs_mount  (bsc#1227150)
  - Add xfsprogs-xfs_copy-don-t-use-cached-buffer-reads-until-after-l.patch

Package xkbcomp was updated:

- U_Ignore-xkb_keycodes.maximum-of-255.patch  * fix keyboard layouts in XWayland applications when having
    several keyboard layouts enabled (boo#1219505)

Package yast2-country was updated:

- Rename Europe/Kiev to Europe/Kyiv as per 2022b release of  tz code and data by ICANN (bsc#1224387)
- 4.5.6

Package yast2-iscsi-client was updated:

- Don't leak passwords to the log (bsc#1225432)- 4.5.9

Package yast2-registration was updated:

- Ensure add_on_others in autoyast profile are added (bsc#1223301)- 4.5.10

Package zypper was updated:

- Fixed check for outdated repo metadata as non-root user  (bsc#1222086)
- BuildRequires:  libzypp-devel &amp;gt;= 17.33.0.
- Delay zypp lock until command options are parsed (bsc#1223766)
- version 1.14.73

- Unify message format(fixes #485)
- version 1.14.72

- switch cmake build type to RelWithDebInfo
- modernize spec file (remove Authors section, use proper macros,
  remove redundant clean section, don't mark man pages as doc)
- switch to -O2 -fvisibility=hidden -fpie:
  * PIC is not needed as no shared lib is built
  * fstack-protector-strong is default on modern dists and would
    be downgraded by fstack-protector
  * default visibility hidden allows better optimisation
  * O2 is reducing inlining bloat
  - &amp;gt; 18% reduced binary size

- remove procps requires (was only for ZMD which is dropped)
  (jsc#PED-8153)

</Note>
    <Note Title="Terms of Use" Type="Legal Disclaimer" Ordinal="3" xml:lang="en">The CVRF data is provided by SUSE under the Creative Commons License 4.0 with Attribution (CC-BY-4.0).</Note>
  </DocumentNotes>
  <DocumentReferences>
    <Reference Type="Self">
      <URL>https://publiccloudimagechangeinfo.suse.com/google/sles-sap-15-sp5-hardened-v20240808-x86-64/</URL>
      <Description>Public Cloud Image Info</Description>
    </Reference>
    <Reference Type="Self">
      <URL>https://www.suse.com/support/security/rating/</URL>
      <Description>SUSE Security Ratings</Description>
    </Reference>
  </DocumentReferences>
  <ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
    <Branch Type="Product Family" Name="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <Branch Type="Product Name" Name="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
        <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
      </Branch>
    </Branch>
    <Branch Type="Product Version" Name="Mesa-22.3.5-150500.77.2.1">
      <FullProductName ProductID="Mesa-22.3.5-150500.77.2.1">Mesa-22.3.5-150500.77.2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="Mesa-dri-22.3.5-150500.77.2.1">
      <FullProductName ProductID="Mesa-dri-22.3.5-150500.77.2.1">Mesa-dri-22.3.5-150500.77.2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="Mesa-gallium-22.3.5-150500.77.2.1">
      <FullProductName ProductID="Mesa-gallium-22.3.5-150500.77.2.1">Mesa-gallium-22.3.5-150500.77.2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="Mesa-libEGL1-22.3.5-150500.77.2.1">
      <FullProductName ProductID="Mesa-libEGL1-22.3.5-150500.77.2.1">Mesa-libEGL1-22.3.5-150500.77.2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="Mesa-libGL1-22.3.5-150500.77.2.1">
      <FullProductName ProductID="Mesa-libGL1-22.3.5-150500.77.2.1">Mesa-libGL1-22.3.5-150500.77.2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="Mesa-libglapi0-22.3.5-150500.77.2.1">
      <FullProductName ProductID="Mesa-libglapi0-22.3.5-150500.77.2.1">Mesa-libglapi0-22.3.5-150500.77.2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="SAPHanaSR-0.162.4-150000.4.44.1">
      <FullProductName ProductID="SAPHanaSR-0.162.4-150000.4.44.1">SAPHanaSR-0.162.4-150000.4.44.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="SAPHanaSR-doc-0.162.4-150000.4.44.1">
      <FullProductName ProductID="SAPHanaSR-doc-0.162.4-150000.4.44.1">SAPHanaSR-doc-0.162.4-150000.4.44.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="aaa_base-84.87+git20180409.04c9dae-150300.10.20.1">
      <FullProductName ProductID="aaa_base-84.87+git20180409.04c9dae-150300.10.20.1">aaa_base-84.87+git20180409.04c9dae-150300.10.20.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="aaa_base-extras-84.87+git20180409.04c9dae-150300.10.20.1">
      <FullProductName ProductID="aaa_base-extras-84.87+git20180409.04c9dae-150300.10.20.1">aaa_base-extras-84.87+git20180409.04c9dae-150300.10.20.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="autofs-5.1.3-150000.7.20.1">
      <FullProductName ProductID="autofs-5.1.3-150000.7.20.1">autofs-5.1.3-150000.7.20.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="chrony-4.1-150400.21.5.7">
      <FullProductName ProductID="chrony-4.1-150400.21.5.7">chrony-4.1-150400.21.5.7</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="chrony-pool-suse-4.1-150400.21.5.7">
      <FullProductName ProductID="chrony-pool-suse-4.1-150400.21.5.7">chrony-pool-suse-4.1-150400.21.5.7</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-10.3.0-150500.2.1">
      <FullProductName ProductID="cloud-regionsrv-client-10.3.0-150500.2.1">cloud-regionsrv-client-10.3.0-150500.2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-plugin-gce-1.0.0-150500.2.1">
      <FullProductName ProductID="cloud-regionsrv-client-plugin-gce-1.0.0-150500.2.1">cloud-regionsrv-client-plugin-gce-1.0.0-150500.2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cluster-md-kmp-default-5.14.21-150500.55.68.1">
      <FullProductName ProductID="cluster-md-kmp-default-5.14.21-150500.55.68.1">cluster-md-kmp-default-5.14.21-150500.55.68.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="containerd-1.7.17-150000.114.1">
      <FullProductName ProductID="containerd-1.7.17-150000.114.1">containerd-1.7.17-150000.114.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="crmsh-4.5.1+20240719.bda4d1e-150500.3.31.2">
      <FullProductName ProductID="crmsh-4.5.1+20240719.bda4d1e-150500.3.31.2">crmsh-4.5.1+20240719.bda4d1e-150500.3.31.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="crmsh-scripts-4.5.1+20240719.bda4d1e-150500.3.31.2">
      <FullProductName ProductID="crmsh-scripts-4.5.1+20240719.bda4d1e-150500.3.31.2">crmsh-scripts-4.5.1+20240719.bda4d1e-150500.3.31.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cups-config-2.2.7-150000.3.62.1">
      <FullProductName ProductID="cups-config-2.2.7-150000.3.62.1">cups-config-2.2.7-150000.3.62.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="desktop-data-SLE-15-150000.4.3.11">
      <FullProductName ProductID="desktop-data-SLE-15-150000.4.3.11">desktop-data-SLE-15-150000.4.3.11</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="dlm-kmp-default-5.14.21-150500.55.68.1">
      <FullProductName ProductID="dlm-kmp-default-5.14.21-150500.55.68.1">dlm-kmp-default-5.14.21-150500.55.68.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="docker-25.0.6_ce-150000.203.1">
      <FullProductName ProductID="docker-25.0.6_ce-150000.203.1">docker-25.0.6_ce-150000.203.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="dracut-055+suse.388.g70c21afa-150500.3.21.2">
      <FullProductName ProductID="dracut-055+suse.388.g70c21afa-150500.3.21.2">dracut-055+suse.388.g70c21afa-150500.3.21.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="fdupes-2.3.0-150400.3.3.1">
      <FullProductName ProductID="fdupes-2.3.0-150400.3.3.1">fdupes-2.3.0-150400.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="gdk-pixbuf-query-loaders-2.42.12-150400.5.9.1">
      <FullProductName ProductID="gdk-pixbuf-query-loaders-2.42.12-150400.5.9.1">gdk-pixbuf-query-loaders-2.42.12-150400.5.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="gfs2-kmp-default-5.14.21-150500.55.68.1">
      <FullProductName ProductID="gfs2-kmp-default-5.14.21-150500.55.68.1">gfs2-kmp-default-5.14.21-150500.55.68.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glib2-tools-2.70.5-150400.3.11.1">
      <FullProductName ProductID="glib2-tools-2.70.5-150400.3.11.1">glib2-tools-2.70.5-150400.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-2.31-150300.83.1">
      <FullProductName ProductID="glibc-2.31-150300.83.1">glibc-2.31-150300.83.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-32bit-2.31-150300.83.1">
      <FullProductName ProductID="glibc-32bit-2.31-150300.83.1">glibc-32bit-2.31-150300.83.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-i18ndata-2.31-150300.83.1">
      <FullProductName ProductID="glibc-i18ndata-2.31-150300.83.1">glibc-i18ndata-2.31-150300.83.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-locale-2.31-150300.83.1">
      <FullProductName ProductID="glibc-locale-2.31-150300.83.1">glibc-locale-2.31-150300.83.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="glibc-locale-base-2.31-150300.83.1">
      <FullProductName ProductID="glibc-locale-base-2.31-150300.83.1">glibc-locale-base-2.31-150300.83.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-cloud-sap-agent-3.4-150100.3.35.1">
      <FullProductName ProductID="google-cloud-sap-agent-3.4-150100.3.35.1">google-cloud-sap-agent-3.4-150100.3.35.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-agent-20240314.00-150400.1.48.7">
      <FullProductName ProductID="google-guest-agent-20240314.00-150400.1.48.7">google-guest-agent-20240314.00-150400.1.48.7</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-configs-20240307.00-150400.13.11.6">
      <FullProductName ProductID="google-guest-configs-20240307.00-150400.13.11.6">google-guest-configs-20240307.00-150400.13.11.6</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-guest-oslogin-20240311.00-150400.1.45.7">
      <FullProductName ProductID="google-guest-oslogin-20240311.00-150400.1.45.7">google-guest-oslogin-20240311.00-150400.1.45.7</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="google-osconfig-agent-20240320.00-150400.1.35.7">
      <FullProductName ProductID="google-osconfig-agent-20240320.00-150400.1.35.7">google-osconfig-agent-20240320.00-150400.1.35.7</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="growpart-rootgrow-1.0.7-150400.1.14.7">
      <FullProductName ProductID="growpart-rootgrow-1.0.7-150400.1.14.7">growpart-rootgrow-1.0.7-150400.1.14.7</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="gtk2-tools-2.24.33-150400.4.3.1">
      <FullProductName ProductID="gtk2-tools-2.24.33-150400.4.3.1">gtk2-tools-2.24.33-150400.4.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="iputils-20221126-150500.3.8.2">
      <FullProductName ProductID="iputils-20221126-150500.3.8.2">iputils-20221126-150500.3.8.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kernel-default-5.14.21-150500.55.68.1">
      <FullProductName ProductID="kernel-default-5.14.21-150500.55.68.1">kernel-default-5.14.21-150500.55.68.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="krb5-1.20.1-150500.3.9.1">
      <FullProductName ProductID="krb5-1.20.1-150500.3.9.1">krb5-1.20.1-150500.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="krb5-client-1.20.1-150500.3.9.1">
      <FullProductName ProductID="krb5-client-1.20.1-150500.3.9.1">krb5-client-1.20.1-150500.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ldirectord-4.12.0+git30.7fd7c8fa-150500.3.9.2">
      <FullProductName ProductID="ldirectord-4.12.0+git30.7fd7c8fa-150500.3.9.2">ldirectord-4.12.0+git30.7fd7c8fa-150500.3.9.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libLLVM15-15.0.7-150500.4.11.1">
      <FullProductName ProductID="libLLVM15-15.0.7-150500.4.11.1">libLLVM15-15.0.7-150500.4.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libQt5Core5-5.15.8+kde185-150500.4.19.1">
      <FullProductName ProductID="libQt5Core5-5.15.8+kde185-150500.4.19.1">libQt5Core5-5.15.8+kde185-150500.4.19.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libQt5DBus5-5.15.8+kde185-150500.4.19.1">
      <FullProductName ProductID="libQt5DBus5-5.15.8+kde185-150500.4.19.1">libQt5DBus5-5.15.8+kde185-150500.4.19.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libQt5Gui5-5.15.8+kde185-150500.4.19.1">
      <FullProductName ProductID="libQt5Gui5-5.15.8+kde185-150500.4.19.1">libQt5Gui5-5.15.8+kde185-150500.4.19.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libQt5Network5-5.15.8+kde185-150500.4.19.1">
      <FullProductName ProductID="libQt5Network5-5.15.8+kde185-150500.4.19.1">libQt5Network5-5.15.8+kde185-150500.4.19.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libQt5Widgets5-5.15.8+kde185-150500.4.19.1">
      <FullProductName ProductID="libQt5Widgets5-5.15.8+kde185-150500.4.19.1">libQt5Widgets5-5.15.8+kde185-150500.4.19.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libassuan0-2.5.5-150000.4.7.1">
      <FullProductName ProductID="libassuan0-2.5.5-150000.4.7.1">libassuan0-2.5.5-150000.4.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libatomic1-13.3.0+git8781-150000.1.12.1">
      <FullProductName ProductID="libatomic1-13.3.0+git8781-150000.1.12.1">libatomic1-13.3.0+git8781-150000.1.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libblkid1-2.37.4-150500.9.11.1">
      <FullProductName ProductID="libblkid1-2.37.4-150500.9.11.1">libblkid1-2.37.4-150500.9.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcups2-2.2.7-150000.3.62.1">
      <FullProductName ProductID="libcups2-2.2.7-150000.3.62.1">libcups2-2.2.7-150000.3.62.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libfdisk1-2.37.4-150500.9.11.1">
      <FullProductName ProductID="libfdisk1-2.37.4-150500.9.11.1">libfdisk1-2.37.4-150500.9.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libfreebl3-3.101.2-150400.3.48.1">
      <FullProductName ProductID="libfreebl3-3.101.2-150400.3.48.1">libfreebl3-3.101.2-150400.3.48.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgbm1-22.3.5-150500.77.2.1">
      <FullProductName ProductID="libgbm1-22.3.5-150500.77.2.1">libgbm1-22.3.5-150500.77.2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgcc_s1-13.3.0+git8781-150000.1.12.1">
      <FullProductName ProductID="libgcc_s1-13.3.0+git8781-150000.1.12.1">libgcc_s1-13.3.0+git8781-150000.1.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgdk_pixbuf-2_0-0-2.42.12-150400.5.9.1">
      <FullProductName ProductID="libgdk_pixbuf-2_0-0-2.42.12-150400.5.9.1">libgdk_pixbuf-2_0-0-2.42.12-150400.5.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgio-2_0-0-2.70.5-150400.3.11.1">
      <FullProductName ProductID="libgio-2_0-0-2.70.5-150400.3.11.1">libgio-2_0-0-2.70.5-150400.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libglib-2_0-0-2.70.5-150400.3.11.1">
      <FullProductName ProductID="libglib-2_0-0-2.70.5-150400.3.11.1">libglib-2_0-0-2.70.5-150400.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgmodule-2_0-0-2.70.5-150400.3.11.1">
      <FullProductName ProductID="libgmodule-2_0-0-2.70.5-150400.3.11.1">libgmodule-2_0-0-2.70.5-150400.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgobject-2_0-0-2.70.5-150400.3.11.1">
      <FullProductName ProductID="libgobject-2_0-0-2.70.5-150400.3.11.1">libgobject-2_0-0-2.70.5-150400.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgthread-2_0-0-2.70.5-150400.3.11.1">
      <FullProductName ProductID="libgthread-2_0-0-2.70.5-150400.3.11.1">libgthread-2_0-0-2.70.5-150400.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libgtk-2_0-0-2.24.33-150400.4.3.1">
      <FullProductName ProductID="libgtk-2_0-0-2.24.33-150400.4.3.1">libgtk-2_0-0-2.24.33-150400.4.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libjitterentropy3-3.4.1-150000.1.12.1">
      <FullProductName ProductID="libjitterentropy3-3.4.1-150000.1.12.1">libjitterentropy3-3.4.1-150000.1.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libltdl7-2.4.6-150000.3.8.1">
      <FullProductName ProductID="libltdl7-2.4.6-150000.3.8.1">libltdl7-2.4.6-150000.3.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libmount1-2.37.4-150500.9.11.1">
      <FullProductName ProductID="libmount1-2.37.4-150500.9.11.1">libmount1-2.37.4-150500.9.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libonig4-6.7.0-150000.3.6.1">
      <FullProductName ProductID="libonig4-6.7.0-150000.3.6.1">libonig4-6.7.0-150000.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libopenscap25-1.3.6-150400.11.5.1">
      <FullProductName ProductID="libopenscap25-1.3.6-150400.11.5.1">libopenscap25-1.3.6-150400.11.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libopenssl1_1-1.1.1l-150500.17.31.1">
      <FullProductName ProductID="libopenssl1_1-1.1.1l-150500.17.31.1">libopenssl1_1-1.1.1l-150500.17.31.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpcsclite1-1.9.4-150400.3.2.1">
      <FullProductName ProductID="libpcsclite1-1.9.4-150400.3.2.1">libpcsclite1-1.9.4-150400.3.2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libprocps8-3.3.17-150000.7.39.1">
      <FullProductName ProductID="libprocps8-3.3.17-150000.7.39.1">libprocps8-3.3.17-150000.7.39.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libprotobuf-lite25_1_0-25.1-150500.12.2.2">
      <FullProductName ProductID="libprotobuf-lite25_1_0-25.1-150500.12.2.2">libprotobuf-lite25_1_0-25.1-150500.12.2.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpython3_6m1_0-3.6.15-150300.10.65.1">
      <FullProductName ProductID="libpython3_6m1_0-3.6.15-150300.10.65.1">libpython3_6m1_0-3.6.15-150300.10.65.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libqb100-2.0.6+20220323.758044b-150500.3.6.2">
      <FullProductName ProductID="libqb100-2.0.6+20220323.758044b-150500.3.6.2">libqb100-2.0.6+20220323.758044b-150500.3.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsmartcols1-2.37.4-150500.9.11.1">
      <FullProductName ProductID="libsmartcols1-2.37.4-150500.9.11.1">libsmartcols1-2.37.4-150500.9.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsoftokn3-3.101.2-150400.3.48.1">
      <FullProductName ProductID="libsoftokn3-3.101.2-150400.3.48.1">libsoftokn3-3.101.2-150400.3.48.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsolv-tools-0.7.29-150400.3.22.4">
      <FullProductName ProductID="libsolv-tools-0.7.29-150400.3.22.4">libsolv-tools-0.7.29-150400.3.22.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libssh2-1-1.11.0-150200.9.2.1">
      <FullProductName ProductID="libssh2-1-1.11.0-150200.9.2.1">libssh2-1-1.11.0-150200.9.2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libstdc++6-13.3.0+git8781-150000.1.12.1">
      <FullProductName ProductID="libstdc++6-13.3.0+git8781-150000.1.12.1">libstdc++6-13.3.0+git8781-150000.1.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsuseconnect-1.11.0-150500.3.26.4">
      <FullProductName ProductID="libsuseconnect-1.11.0-150500.3.26.4">libsuseconnect-1.11.0-150500.3.26.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libtiff5-4.0.9-150000.45.44.1">
      <FullProductName ProductID="libtiff5-4.0.9-150000.45.44.1">libtiff5-4.0.9-150000.45.44.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libuuid1-2.37.4-150500.9.11.1">
      <FullProductName ProductID="libuuid1-2.37.4-150500.9.11.1">libuuid1-2.37.4-150500.9.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libvirt-client-9.0.0-150500.6.23.1">
      <FullProductName ProductID="libvirt-client-9.0.0-150500.6.23.1">libvirt-client-9.0.0-150500.6.23.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libvirt-libs-9.0.0-150500.6.23.1">
      <FullProductName ProductID="libvirt-libs-9.0.0-150500.6.23.1">libvirt-libs-9.0.0-150500.6.23.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxcb-dri2-0-1.13-150000.3.11.1">
      <FullProductName ProductID="libxcb-dri2-0-1.13-150000.3.11.1">libxcb-dri2-0-1.13-150000.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxcb-dri3-0-1.13-150000.3.11.1">
      <FullProductName ProductID="libxcb-dri3-0-1.13-150000.3.11.1">libxcb-dri3-0-1.13-150000.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxcb-glx0-1.13-150000.3.11.1">
      <FullProductName ProductID="libxcb-glx0-1.13-150000.3.11.1">libxcb-glx0-1.13-150000.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxcb-present0-1.13-150000.3.11.1">
      <FullProductName ProductID="libxcb-present0-1.13-150000.3.11.1">libxcb-present0-1.13-150000.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxcb-randr0-1.13-150000.3.11.1">
      <FullProductName ProductID="libxcb-randr0-1.13-150000.3.11.1">libxcb-randr0-1.13-150000.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxcb-render0-1.13-150000.3.11.1">
      <FullProductName ProductID="libxcb-render0-1.13-150000.3.11.1">libxcb-render0-1.13-150000.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxcb-shape0-1.13-150000.3.11.1">
      <FullProductName ProductID="libxcb-shape0-1.13-150000.3.11.1">libxcb-shape0-1.13-150000.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxcb-shm0-1.13-150000.3.11.1">
      <FullProductName ProductID="libxcb-shm0-1.13-150000.3.11.1">libxcb-shm0-1.13-150000.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxcb-sync1-1.13-150000.3.11.1">
      <FullProductName ProductID="libxcb-sync1-1.13-150000.3.11.1">libxcb-sync1-1.13-150000.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxcb-xfixes0-1.13-150000.3.11.1">
      <FullProductName ProductID="libxcb-xfixes0-1.13-150000.3.11.1">libxcb-xfixes0-1.13-150000.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxcb-xinerama0-1.13-150000.3.11.1">
      <FullProductName ProductID="libxcb-xinerama0-1.13-150000.3.11.1">libxcb-xinerama0-1.13-150000.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxcb-xinput0-1.13-150000.3.11.1">
      <FullProductName ProductID="libxcb-xinput0-1.13-150000.3.11.1">libxcb-xinput0-1.13-150000.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxcb-xkb1-1.13-150000.3.11.1">
      <FullProductName ProductID="libxcb-xkb1-1.13-150000.3.11.1">libxcb-xkb1-1.13-150000.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxcb1-1.13-150000.3.11.1">
      <FullProductName ProductID="libxcb1-1.13-150000.3.11.1">libxcb1-1.13-150000.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxml2-2-2.10.3-150500.5.17.1">
      <FullProductName ProductID="libxml2-2-2.10.3-150500.5.17.1">libxml2-2-2.10.3-150500.5.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxml2-tools-2.10.3-150500.5.17.1">
      <FullProductName ProductID="libxml2-tools-2.10.3-150500.5.17.1">libxml2-tools-2.10.3-150500.5.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxmlsec1-1-1.2.37-150400.14.5.1">
      <FullProductName ProductID="libxmlsec1-1-1.2.37-150400.14.5.1">libxmlsec1-1-1.2.37-150400.14.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxmlsec1-openssl1-1.2.37-150400.14.5.1">
      <FullProductName ProductID="libxmlsec1-openssl1-1.2.37-150400.14.5.1">libxmlsec1-openssl1-1.2.37-150400.14.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libyui-ncurses-pkg16-4.5.3-150500.3.7.9">
      <FullProductName ProductID="libyui-ncurses-pkg16-4.5.3-150500.3.7.9">libyui-ncurses-pkg16-4.5.3-150500.3.7.9</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libyui-ncurses16-4.5.3-150500.3.7.8">
      <FullProductName ProductID="libyui-ncurses16-4.5.3-150500.3.7.8">libyui-ncurses16-4.5.3-150500.3.7.8</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libyui-qt16-4.5.3-150500.3.7.8">
      <FullProductName ProductID="libyui-qt16-4.5.3-150500.3.7.8">libyui-qt16-4.5.3-150500.3.7.8</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libyui16-4.5.3-150500.3.7.8">
      <FullProductName ProductID="libyui16-4.5.3-150500.3.7.8">libyui16-4.5.3-150500.3.7.8</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libzypp-17.34.1-150500.6.2.1">
      <FullProductName ProductID="libzypp-17.34.1-150500.6.2.1">libzypp-17.34.1-150500.6.2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="lifecycle-data-sle-module-live-patching-15-150000.4.114.2">
      <FullProductName ProductID="lifecycle-data-sle-module-live-patching-15-150000.4.114.2">lifecycle-data-sle-module-live-patching-15-150000.4.114.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="login_defs-4.8.1-150400.10.21.1">
      <FullProductName ProductID="login_defs-4.8.1-150400.10.21.1">login_defs-4.8.1-150400.10.21.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nss-3.101.2-150400.3.48.1">
      <FullProductName ProductID="mozilla-nss-3.101.2-150400.3.48.1">mozilla-nss-3.101.2-150400.3.48.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nss-certs-3.101.2-150400.3.48.1">
      <FullProductName ProductID="mozilla-nss-certs-3.101.2-150400.3.48.1">mozilla-nss-certs-3.101.2-150400.3.48.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="mozilla-nss-tools-3.101.2-150400.3.48.1">
      <FullProductName ProductID="mozilla-nss-tools-3.101.2-150400.3.48.1">mozilla-nss-tools-3.101.2-150400.3.48.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="nscd-2.31-150300.83.1">
      <FullProductName ProductID="nscd-2.31-150300.83.1">nscd-2.31-150300.83.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ocfs2-kmp-default-5.14.21-150500.55.68.1">
      <FullProductName ProductID="ocfs2-kmp-default-5.14.21-150500.55.68.1">ocfs2-kmp-default-5.14.21-150500.55.68.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ocfs2-tools-1.8.7-150500.12.6.2">
      <FullProductName ProductID="ocfs2-tools-1.8.7-150500.12.6.2">ocfs2-tools-1.8.7-150500.12.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openscap-1.3.6-150400.11.5.1">
      <FullProductName ProductID="openscap-1.3.6-150400.11.5.1">openscap-1.3.6-150400.11.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openscap-utils-1.3.6-150400.11.5.1">
      <FullProductName ProductID="openscap-utils-1.3.6-150400.11.5.1">openscap-utils-1.3.6-150400.11.5.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssl-1_1-1.1.1l-150500.17.31.1">
      <FullProductName ProductID="openssl-1_1-1.1.1l-150500.17.31.1">openssl-1_1-1.1.1l-150500.17.31.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pacemaker-2.1.5+20221208.a3f44794f-150500.6.17.1">
      <FullProductName ProductID="pacemaker-2.1.5+20221208.a3f44794f-150500.6.17.1">pacemaker-2.1.5+20221208.a3f44794f-150500.6.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pacemaker-cli-2.1.5+20221208.a3f44794f-150500.6.17.1">
      <FullProductName ProductID="pacemaker-cli-2.1.5+20221208.a3f44794f-150500.6.17.1">pacemaker-cli-2.1.5+20221208.a3f44794f-150500.6.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pacemaker-libs-2.1.5+20221208.a3f44794f-150500.6.17.1">
      <FullProductName ProductID="pacemaker-libs-2.1.5+20221208.a3f44794f-150500.6.17.1">pacemaker-libs-2.1.5+20221208.a3f44794f-150500.6.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="patterns-base-base-20200124-150400.20.10.1">
      <FullProductName ProductID="patterns-base-base-20200124-150400.20.10.1">patterns-base-base-20200124-150400.20.10.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="patterns-base-basesystem-20200124-150400.20.10.1">
      <FullProductName ProductID="patterns-base-basesystem-20200124-150400.20.10.1">patterns-base-basesystem-20200124-150400.20.10.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="patterns-base-minimal_base-20200124-150400.20.10.1">
      <FullProductName ProductID="patterns-base-minimal_base-20200124-150400.20.10.1">patterns-base-minimal_base-20200124-150400.20.10.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pcsc-lite-1.9.4-150400.3.2.1">
      <FullProductName ProductID="pcsc-lite-1.9.4-150400.3.2.1">pcsc-lite-1.9.4-150400.3.2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="procps-3.3.17-150000.7.39.1">
      <FullProductName ProductID="procps-3.3.17-150000.7.39.1">procps-3.3.17-150000.7.39.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python-instance-billing-flavor-check-0.0.6-150400.1.11.7">
      <FullProductName ProductID="python-instance-billing-flavor-check-0.0.6-150400.1.11.7">python-instance-billing-flavor-check-0.0.6-150400.1.11.7</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-3.6.15-150300.10.65.2">
      <FullProductName ProductID="python3-3.6.15-150300.10.65.2">python3-3.6.15-150300.10.65.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-base-3.6.15-150300.10.65.1">
      <FullProductName ProductID="python3-base-3.6.15-150300.10.65.1">python3-base-3.6.15-150300.10.65.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-cssselect-1.0.3-150400.3.7.4">
      <FullProductName ProductID="python3-cssselect-1.0.3-150400.3.7.4">python3-cssselect-1.0.3-150400.3.7.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-curses-3.6.15-150300.10.65.2">
      <FullProductName ProductID="python3-curses-3.6.15-150300.10.65.2">python3-curses-3.6.15-150300.10.65.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-lxml-4.9.1-150500.3.4.3">
      <FullProductName ProductID="python3-lxml-4.9.1-150500.3.4.3">python3-lxml-4.9.1-150500.3.4.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-requests-2.25.1-150300.3.12.2">
      <FullProductName ProductID="python3-requests-2.25.1-150300.3.12.2">python3-requests-2.25.1-150300.3.12.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-solv-0.7.29-150400.3.22.4">
      <FullProductName ProductID="python3-solv-0.7.29-150400.3.22.4">python3-solv-0.7.29-150400.3.22.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-urllib3-1.25.10-150300.4.12.1">
      <FullProductName ProductID="python3-urllib3-1.25.10-150300.4.12.1">python3-urllib3-1.25.10-150300.4.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="resource-agents-4.12.0+git30.7fd7c8fa-150500.3.9.2">
      <FullProductName ProductID="resource-agents-4.12.0+git30.7fd7c8fa-150500.3.9.2">resource-agents-4.12.0+git30.7fd7c8fa-150500.3.9.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby-solv-0.7.29-150400.3.22.4">
      <FullProductName ProductID="ruby-solv-0.7.29-150400.3.22.4">ruby-solv-0.7.29-150400.3.22.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ruby2.5-rubygem-sass-3.7.4-150000.3.3.1">
      <FullProductName ProductID="ruby2.5-rubygem-sass-3.7.4-150000.3.3.1">ruby2.5-rubygem-sass-3.7.4-150000.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="runc-1.1.13-150000.67.1">
      <FullProductName ProductID="runc-1.1.13-150000.67.1">runc-1.1.13-150000.67.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="scap-security-guide-0.1.73-150000.1.83.1">
      <FullProductName ProductID="scap-security-guide-0.1.73-150000.1.83.1">scap-security-guide-0.1.73-150000.1.83.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="shadow-4.8.1-150400.10.21.1">
      <FullProductName ProductID="shadow-4.8.1-150400.10.21.1">shadow-4.8.1-150400.10.21.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="socat-1.8.0.0-150400.14.3.1">
      <FullProductName ProductID="socat-1.8.0.0-150400.14.3.1">socat-1.8.0.0-150400.14.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="supportutils-3.1.30-150300.7.35.30.1">
      <FullProductName ProductID="supportutils-3.1.30-150300.7.35.30.1">supportutils-3.1.30-150300.7.35.30.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suse-build-key-12.0-150000.8.49.2">
      <FullProductName ProductID="suse-build-key-12.0-150000.8.49.2">suse-build-key-12.0-150000.8.49.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suse-module-tools-15.5.5-150500.3.12.2">
      <FullProductName ProductID="suse-module-tools-15.5.5-150500.3.12.2">suse-module-tools-15.5.5-150500.3.12.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suseconnect-ng-1.11.0-150500.3.26.4">
      <FullProductName ProductID="suseconnect-ng-1.11.0-150500.3.26.4">suseconnect-ng-1.11.0-150500.3.26.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suseconnect-ruby-bindings-1.11.0-150500.3.26.4">
      <FullProductName ProductID="suseconnect-ruby-bindings-1.11.0-150500.3.26.4">suseconnect-ruby-bindings-1.11.0-150500.3.26.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="util-linux-2.37.4-150500.9.11.1">
      <FullProductName ProductID="util-linux-2.37.4-150500.9.11.1">util-linux-2.37.4-150500.9.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="util-linux-systemd-2.37.4-150500.9.11.1">
      <FullProductName ProductID="util-linux-systemd-2.37.4-150500.9.11.1">util-linux-systemd-2.37.4-150500.9.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="uuidd-2.37.4-150500.9.11.1">
      <FullProductName ProductID="uuidd-2.37.4-150500.9.11.1">uuidd-2.37.4-150500.9.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wget-1.20.3-150000.3.20.1">
      <FullProductName ProductID="wget-1.20.3-150000.3.20.1">wget-1.20.3-150000.3.20.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wicked-0.6.76-150500.3.33.1">
      <FullProductName ProductID="wicked-0.6.76-150500.3.33.1">wicked-0.6.76-150500.3.33.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wicked-service-0.6.76-150500.3.33.1">
      <FullProductName ProductID="wicked-service-0.6.76-150500.3.33.1">wicked-service-0.6.76-150500.3.33.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="xen-libs-4.17.4_04-150500.3.33.1">
      <FullProductName ProductID="xen-libs-4.17.4_04-150500.3.33.1">xen-libs-4.17.4_04-150500.3.33.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="xfsprogs-5.13.0-150400.3.10.2">
      <FullProductName ProductID="xfsprogs-5.13.0-150400.3.10.2">xfsprogs-5.13.0-150400.3.10.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="xkbcomp-1.4.1-150000.3.3.2">
      <FullProductName ProductID="xkbcomp-1.4.1-150000.3.3.2">xkbcomp-1.4.1-150000.3.3.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-country-4.5.6-150500.3.3.2">
      <FullProductName ProductID="yast2-country-4.5.6-150500.3.3.2">yast2-country-4.5.6-150500.3.3.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-country-data-4.5.6-150500.3.3.2">
      <FullProductName ProductID="yast2-country-data-4.5.6-150500.3.3.2">yast2-country-data-4.5.6-150500.3.3.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-iscsi-client-4.5.9-150500.3.6.2">
      <FullProductName ProductID="yast2-iscsi-client-4.5.9-150500.3.6.2">yast2-iscsi-client-4.5.9-150500.3.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-pkg-bindings-4.5.3-150500.3.7.17">
      <FullProductName ProductID="yast2-pkg-bindings-4.5.3-150500.3.7.17">yast2-pkg-bindings-4.5.3-150500.3.7.17</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-registration-4.5.10-150500.3.6.2">
      <FullProductName ProductID="yast2-registration-4.5.10-150500.3.6.2">yast2-registration-4.5.10-150500.3.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="zypper-1.14.73-150500.6.2.1">
      <FullProductName ProductID="zypper-1.14.73-150500.6.2.1">zypper-1.14.73-150500.6.2.1</FullProductName>
    </Branch>
    <Relationship ProductReference="Mesa-22.3.5-150500.77.2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:Mesa-22.3.5-150500.77.2.1">Mesa-22.3.5-150500.77.2.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="Mesa-dri-22.3.5-150500.77.2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:Mesa-dri-22.3.5-150500.77.2.1">Mesa-dri-22.3.5-150500.77.2.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="Mesa-gallium-22.3.5-150500.77.2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:Mesa-gallium-22.3.5-150500.77.2.1">Mesa-gallium-22.3.5-150500.77.2.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="Mesa-libEGL1-22.3.5-150500.77.2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:Mesa-libEGL1-22.3.5-150500.77.2.1">Mesa-libEGL1-22.3.5-150500.77.2.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="Mesa-libGL1-22.3.5-150500.77.2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:Mesa-libGL1-22.3.5-150500.77.2.1">Mesa-libGL1-22.3.5-150500.77.2.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="Mesa-libglapi0-22.3.5-150500.77.2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:Mesa-libglapi0-22.3.5-150500.77.2.1">Mesa-libglapi0-22.3.5-150500.77.2.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="SAPHanaSR-0.162.4-150000.4.44.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:SAPHanaSR-0.162.4-150000.4.44.1">SAPHanaSR-0.162.4-150000.4.44.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="SAPHanaSR-doc-0.162.4-150000.4.44.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:SAPHanaSR-doc-0.162.4-150000.4.44.1">SAPHanaSR-doc-0.162.4-150000.4.44.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="aaa_base-84.87+git20180409.04c9dae-150300.10.20.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:aaa_base-84.87+git20180409.04c9dae-150300.10.20.1">aaa_base-84.87+git20180409.04c9dae-150300.10.20.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="aaa_base-extras-84.87+git20180409.04c9dae-150300.10.20.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:aaa_base-extras-84.87+git20180409.04c9dae-150300.10.20.1">aaa_base-extras-84.87+git20180409.04c9dae-150300.10.20.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="autofs-5.1.3-150000.7.20.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:autofs-5.1.3-150000.7.20.1">autofs-5.1.3-150000.7.20.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="chrony-4.1-150400.21.5.7" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:chrony-4.1-150400.21.5.7">chrony-4.1-150400.21.5.7 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="chrony-pool-suse-4.1-150400.21.5.7" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:chrony-pool-suse-4.1-150400.21.5.7">chrony-pool-suse-4.1-150400.21.5.7 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-10.3.0-150500.2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:cloud-regionsrv-client-10.3.0-150500.2.1">cloud-regionsrv-client-10.3.0-150500.2.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-plugin-gce-1.0.0-150500.2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:cloud-regionsrv-client-plugin-gce-1.0.0-150500.2.1">cloud-regionsrv-client-plugin-gce-1.0.0-150500.2.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cluster-md-kmp-default-5.14.21-150500.55.68.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:cluster-md-kmp-default-5.14.21-150500.55.68.1">cluster-md-kmp-default-5.14.21-150500.55.68.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="containerd-1.7.17-150000.114.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:containerd-1.7.17-150000.114.1">containerd-1.7.17-150000.114.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="crmsh-4.5.1+20240719.bda4d1e-150500.3.31.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:crmsh-4.5.1+20240719.bda4d1e-150500.3.31.2">crmsh-4.5.1+20240719.bda4d1e-150500.3.31.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="crmsh-scripts-4.5.1+20240719.bda4d1e-150500.3.31.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:crmsh-scripts-4.5.1+20240719.bda4d1e-150500.3.31.2">crmsh-scripts-4.5.1+20240719.bda4d1e-150500.3.31.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cups-config-2.2.7-150000.3.62.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:cups-config-2.2.7-150000.3.62.1">cups-config-2.2.7-150000.3.62.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="desktop-data-SLE-15-150000.4.3.11" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:desktop-data-SLE-15-150000.4.3.11">desktop-data-SLE-15-150000.4.3.11 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="dlm-kmp-default-5.14.21-150500.55.68.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:dlm-kmp-default-5.14.21-150500.55.68.1">dlm-kmp-default-5.14.21-150500.55.68.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="docker-25.0.6_ce-150000.203.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:docker-25.0.6_ce-150000.203.1">docker-25.0.6_ce-150000.203.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="dracut-055+suse.388.g70c21afa-150500.3.21.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:dracut-055+suse.388.g70c21afa-150500.3.21.2">dracut-055+suse.388.g70c21afa-150500.3.21.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="fdupes-2.3.0-150400.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:fdupes-2.3.0-150400.3.3.1">fdupes-2.3.0-150400.3.3.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="gdk-pixbuf-query-loaders-2.42.12-150400.5.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:gdk-pixbuf-query-loaders-2.42.12-150400.5.9.1">gdk-pixbuf-query-loaders-2.42.12-150400.5.9.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="gfs2-kmp-default-5.14.21-150500.55.68.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:gfs2-kmp-default-5.14.21-150500.55.68.1">gfs2-kmp-default-5.14.21-150500.55.68.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glib2-tools-2.70.5-150400.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:glib2-tools-2.70.5-150400.3.11.1">glib2-tools-2.70.5-150400.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-2.31-150300.83.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:glibc-2.31-150300.83.1">glibc-2.31-150300.83.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-32bit-2.31-150300.83.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:glibc-32bit-2.31-150300.83.1">glibc-32bit-2.31-150300.83.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-i18ndata-2.31-150300.83.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:glibc-i18ndata-2.31-150300.83.1">glibc-i18ndata-2.31-150300.83.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-locale-2.31-150300.83.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:glibc-locale-2.31-150300.83.1">glibc-locale-2.31-150300.83.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="glibc-locale-base-2.31-150300.83.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:glibc-locale-base-2.31-150300.83.1">glibc-locale-base-2.31-150300.83.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-cloud-sap-agent-3.4-150100.3.35.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:google-cloud-sap-agent-3.4-150100.3.35.1">google-cloud-sap-agent-3.4-150100.3.35.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-agent-20240314.00-150400.1.48.7" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:google-guest-agent-20240314.00-150400.1.48.7">google-guest-agent-20240314.00-150400.1.48.7 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-configs-20240307.00-150400.13.11.6" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:google-guest-configs-20240307.00-150400.13.11.6">google-guest-configs-20240307.00-150400.13.11.6 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-guest-oslogin-20240311.00-150400.1.45.7" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:google-guest-oslogin-20240311.00-150400.1.45.7">google-guest-oslogin-20240311.00-150400.1.45.7 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="google-osconfig-agent-20240320.00-150400.1.35.7" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:google-osconfig-agent-20240320.00-150400.1.35.7">google-osconfig-agent-20240320.00-150400.1.35.7 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="growpart-rootgrow-1.0.7-150400.1.14.7" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:growpart-rootgrow-1.0.7-150400.1.14.7">growpart-rootgrow-1.0.7-150400.1.14.7 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="gtk2-tools-2.24.33-150400.4.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:gtk2-tools-2.24.33-150400.4.3.1">gtk2-tools-2.24.33-150400.4.3.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="iputils-20221126-150500.3.8.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:iputils-20221126-150500.3.8.2">iputils-20221126-150500.3.8.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kernel-default-5.14.21-150500.55.68.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:kernel-default-5.14.21-150500.55.68.1">kernel-default-5.14.21-150500.55.68.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="krb5-1.20.1-150500.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:krb5-1.20.1-150500.3.9.1">krb5-1.20.1-150500.3.9.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="krb5-client-1.20.1-150500.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:krb5-client-1.20.1-150500.3.9.1">krb5-client-1.20.1-150500.3.9.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ldirectord-4.12.0+git30.7fd7c8fa-150500.3.9.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:ldirectord-4.12.0+git30.7fd7c8fa-150500.3.9.2">ldirectord-4.12.0+git30.7fd7c8fa-150500.3.9.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libLLVM15-15.0.7-150500.4.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libLLVM15-15.0.7-150500.4.11.1">libLLVM15-15.0.7-150500.4.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libQt5Core5-5.15.8+kde185-150500.4.19.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libQt5Core5-5.15.8+kde185-150500.4.19.1">libQt5Core5-5.15.8+kde185-150500.4.19.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libQt5DBus5-5.15.8+kde185-150500.4.19.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libQt5DBus5-5.15.8+kde185-150500.4.19.1">libQt5DBus5-5.15.8+kde185-150500.4.19.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libQt5Gui5-5.15.8+kde185-150500.4.19.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libQt5Gui5-5.15.8+kde185-150500.4.19.1">libQt5Gui5-5.15.8+kde185-150500.4.19.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libQt5Network5-5.15.8+kde185-150500.4.19.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libQt5Network5-5.15.8+kde185-150500.4.19.1">libQt5Network5-5.15.8+kde185-150500.4.19.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libQt5Widgets5-5.15.8+kde185-150500.4.19.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libQt5Widgets5-5.15.8+kde185-150500.4.19.1">libQt5Widgets5-5.15.8+kde185-150500.4.19.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libassuan0-2.5.5-150000.4.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libassuan0-2.5.5-150000.4.7.1">libassuan0-2.5.5-150000.4.7.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libatomic1-13.3.0+git8781-150000.1.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libatomic1-13.3.0+git8781-150000.1.12.1">libatomic1-13.3.0+git8781-150000.1.12.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libblkid1-2.37.4-150500.9.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libblkid1-2.37.4-150500.9.11.1">libblkid1-2.37.4-150500.9.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcups2-2.2.7-150000.3.62.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libcups2-2.2.7-150000.3.62.1">libcups2-2.2.7-150000.3.62.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfdisk1-2.37.4-150500.9.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libfdisk1-2.37.4-150500.9.11.1">libfdisk1-2.37.4-150500.9.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfreebl3-3.101.2-150400.3.48.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libfreebl3-3.101.2-150400.3.48.1">libfreebl3-3.101.2-150400.3.48.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgbm1-22.3.5-150500.77.2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libgbm1-22.3.5-150500.77.2.1">libgbm1-22.3.5-150500.77.2.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgcc_s1-13.3.0+git8781-150000.1.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libgcc_s1-13.3.0+git8781-150000.1.12.1">libgcc_s1-13.3.0+git8781-150000.1.12.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgdk_pixbuf-2_0-0-2.42.12-150400.5.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libgdk_pixbuf-2_0-0-2.42.12-150400.5.9.1">libgdk_pixbuf-2_0-0-2.42.12-150400.5.9.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgio-2_0-0-2.70.5-150400.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libgio-2_0-0-2.70.5-150400.3.11.1">libgio-2_0-0-2.70.5-150400.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libglib-2_0-0-2.70.5-150400.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libglib-2_0-0-2.70.5-150400.3.11.1">libglib-2_0-0-2.70.5-150400.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgmodule-2_0-0-2.70.5-150400.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libgmodule-2_0-0-2.70.5-150400.3.11.1">libgmodule-2_0-0-2.70.5-150400.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgobject-2_0-0-2.70.5-150400.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libgobject-2_0-0-2.70.5-150400.3.11.1">libgobject-2_0-0-2.70.5-150400.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgthread-2_0-0-2.70.5-150400.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libgthread-2_0-0-2.70.5-150400.3.11.1">libgthread-2_0-0-2.70.5-150400.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgtk-2_0-0-2.24.33-150400.4.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libgtk-2_0-0-2.24.33-150400.4.3.1">libgtk-2_0-0-2.24.33-150400.4.3.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libjitterentropy3-3.4.1-150000.1.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libjitterentropy3-3.4.1-150000.1.12.1">libjitterentropy3-3.4.1-150000.1.12.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libltdl7-2.4.6-150000.3.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libltdl7-2.4.6-150000.3.8.1">libltdl7-2.4.6-150000.3.8.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libmount1-2.37.4-150500.9.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libmount1-2.37.4-150500.9.11.1">libmount1-2.37.4-150500.9.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libonig4-6.7.0-150000.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libonig4-6.7.0-150000.3.6.1">libonig4-6.7.0-150000.3.6.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libopenscap25-1.3.6-150400.11.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libopenscap25-1.3.6-150400.11.5.1">libopenscap25-1.3.6-150400.11.5.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libopenssl1_1-1.1.1l-150500.17.31.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libopenssl1_1-1.1.1l-150500.17.31.1">libopenssl1_1-1.1.1l-150500.17.31.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpcsclite1-1.9.4-150400.3.2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libpcsclite1-1.9.4-150400.3.2.1">libpcsclite1-1.9.4-150400.3.2.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libprocps8-3.3.17-150000.7.39.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libprocps8-3.3.17-150000.7.39.1">libprocps8-3.3.17-150000.7.39.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libprotobuf-lite25_1_0-25.1-150500.12.2.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libprotobuf-lite25_1_0-25.1-150500.12.2.2">libprotobuf-lite25_1_0-25.1-150500.12.2.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpython3_6m1_0-3.6.15-150300.10.65.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libpython3_6m1_0-3.6.15-150300.10.65.1">libpython3_6m1_0-3.6.15-150300.10.65.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libqb100-2.0.6+20220323.758044b-150500.3.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libqb100-2.0.6+20220323.758044b-150500.3.6.2">libqb100-2.0.6+20220323.758044b-150500.3.6.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsmartcols1-2.37.4-150500.9.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libsmartcols1-2.37.4-150500.9.11.1">libsmartcols1-2.37.4-150500.9.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsoftokn3-3.101.2-150400.3.48.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libsoftokn3-3.101.2-150400.3.48.1">libsoftokn3-3.101.2-150400.3.48.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsolv-tools-0.7.29-150400.3.22.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libsolv-tools-0.7.29-150400.3.22.4">libsolv-tools-0.7.29-150400.3.22.4 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libssh2-1-1.11.0-150200.9.2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libssh2-1-1.11.0-150200.9.2.1">libssh2-1-1.11.0-150200.9.2.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libstdc++6-13.3.0+git8781-150000.1.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libstdc++6-13.3.0+git8781-150000.1.12.1">libstdc++6-13.3.0+git8781-150000.1.12.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsuseconnect-1.11.0-150500.3.26.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libsuseconnect-1.11.0-150500.3.26.4">libsuseconnect-1.11.0-150500.3.26.4 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libtiff5-4.0.9-150000.45.44.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libtiff5-4.0.9-150000.45.44.1">libtiff5-4.0.9-150000.45.44.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libuuid1-2.37.4-150500.9.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libuuid1-2.37.4-150500.9.11.1">libuuid1-2.37.4-150500.9.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libvirt-client-9.0.0-150500.6.23.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libvirt-client-9.0.0-150500.6.23.1">libvirt-client-9.0.0-150500.6.23.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libvirt-libs-9.0.0-150500.6.23.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libvirt-libs-9.0.0-150500.6.23.1">libvirt-libs-9.0.0-150500.6.23.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxcb-dri2-0-1.13-150000.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxcb-dri2-0-1.13-150000.3.11.1">libxcb-dri2-0-1.13-150000.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxcb-dri3-0-1.13-150000.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxcb-dri3-0-1.13-150000.3.11.1">libxcb-dri3-0-1.13-150000.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxcb-glx0-1.13-150000.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxcb-glx0-1.13-150000.3.11.1">libxcb-glx0-1.13-150000.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxcb-present0-1.13-150000.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxcb-present0-1.13-150000.3.11.1">libxcb-present0-1.13-150000.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxcb-randr0-1.13-150000.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxcb-randr0-1.13-150000.3.11.1">libxcb-randr0-1.13-150000.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxcb-render0-1.13-150000.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxcb-render0-1.13-150000.3.11.1">libxcb-render0-1.13-150000.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxcb-shape0-1.13-150000.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxcb-shape0-1.13-150000.3.11.1">libxcb-shape0-1.13-150000.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxcb-shm0-1.13-150000.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxcb-shm0-1.13-150000.3.11.1">libxcb-shm0-1.13-150000.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxcb-sync1-1.13-150000.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxcb-sync1-1.13-150000.3.11.1">libxcb-sync1-1.13-150000.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxcb-xfixes0-1.13-150000.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxcb-xfixes0-1.13-150000.3.11.1">libxcb-xfixes0-1.13-150000.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxcb-xinerama0-1.13-150000.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxcb-xinerama0-1.13-150000.3.11.1">libxcb-xinerama0-1.13-150000.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxcb-xinput0-1.13-150000.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxcb-xinput0-1.13-150000.3.11.1">libxcb-xinput0-1.13-150000.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxcb-xkb1-1.13-150000.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxcb-xkb1-1.13-150000.3.11.1">libxcb-xkb1-1.13-150000.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxcb1-1.13-150000.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxcb1-1.13-150000.3.11.1">libxcb1-1.13-150000.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxml2-2-2.10.3-150500.5.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxml2-2-2.10.3-150500.5.17.1">libxml2-2-2.10.3-150500.5.17.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxml2-tools-2.10.3-150500.5.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxml2-tools-2.10.3-150500.5.17.1">libxml2-tools-2.10.3-150500.5.17.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxmlsec1-1-1.2.37-150400.14.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxmlsec1-1-1.2.37-150400.14.5.1">libxmlsec1-1-1.2.37-150400.14.5.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxmlsec1-openssl1-1.2.37-150400.14.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libxmlsec1-openssl1-1.2.37-150400.14.5.1">libxmlsec1-openssl1-1.2.37-150400.14.5.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libyui-ncurses-pkg16-4.5.3-150500.3.7.9" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libyui-ncurses-pkg16-4.5.3-150500.3.7.9">libyui-ncurses-pkg16-4.5.3-150500.3.7.9 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libyui-ncurses16-4.5.3-150500.3.7.8" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libyui-ncurses16-4.5.3-150500.3.7.8">libyui-ncurses16-4.5.3-150500.3.7.8 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libyui-qt16-4.5.3-150500.3.7.8" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libyui-qt16-4.5.3-150500.3.7.8">libyui-qt16-4.5.3-150500.3.7.8 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libyui16-4.5.3-150500.3.7.8" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libyui16-4.5.3-150500.3.7.8">libyui16-4.5.3-150500.3.7.8 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libzypp-17.34.1-150500.6.2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:libzypp-17.34.1-150500.6.2.1">libzypp-17.34.1-150500.6.2.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="lifecycle-data-sle-module-live-patching-15-150000.4.114.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:lifecycle-data-sle-module-live-patching-15-150000.4.114.2">lifecycle-data-sle-module-live-patching-15-150000.4.114.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="login_defs-4.8.1-150400.10.21.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:login_defs-4.8.1-150400.10.21.1">login_defs-4.8.1-150400.10.21.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nss-3.101.2-150400.3.48.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:mozilla-nss-3.101.2-150400.3.48.1">mozilla-nss-3.101.2-150400.3.48.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nss-certs-3.101.2-150400.3.48.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:mozilla-nss-certs-3.101.2-150400.3.48.1">mozilla-nss-certs-3.101.2-150400.3.48.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="mozilla-nss-tools-3.101.2-150400.3.48.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:mozilla-nss-tools-3.101.2-150400.3.48.1">mozilla-nss-tools-3.101.2-150400.3.48.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="nscd-2.31-150300.83.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:nscd-2.31-150300.83.1">nscd-2.31-150300.83.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ocfs2-kmp-default-5.14.21-150500.55.68.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:ocfs2-kmp-default-5.14.21-150500.55.68.1">ocfs2-kmp-default-5.14.21-150500.55.68.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ocfs2-tools-1.8.7-150500.12.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:ocfs2-tools-1.8.7-150500.12.6.2">ocfs2-tools-1.8.7-150500.12.6.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openscap-1.3.6-150400.11.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:openscap-1.3.6-150400.11.5.1">openscap-1.3.6-150400.11.5.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openscap-utils-1.3.6-150400.11.5.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:openscap-utils-1.3.6-150400.11.5.1">openscap-utils-1.3.6-150400.11.5.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssl-1_1-1.1.1l-150500.17.31.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:openssl-1_1-1.1.1l-150500.17.31.1">openssl-1_1-1.1.1l-150500.17.31.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pacemaker-2.1.5+20221208.a3f44794f-150500.6.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:pacemaker-2.1.5+20221208.a3f44794f-150500.6.17.1">pacemaker-2.1.5+20221208.a3f44794f-150500.6.17.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pacemaker-cli-2.1.5+20221208.a3f44794f-150500.6.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:pacemaker-cli-2.1.5+20221208.a3f44794f-150500.6.17.1">pacemaker-cli-2.1.5+20221208.a3f44794f-150500.6.17.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pacemaker-libs-2.1.5+20221208.a3f44794f-150500.6.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:pacemaker-libs-2.1.5+20221208.a3f44794f-150500.6.17.1">pacemaker-libs-2.1.5+20221208.a3f44794f-150500.6.17.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="patterns-base-base-20200124-150400.20.10.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:patterns-base-base-20200124-150400.20.10.1">patterns-base-base-20200124-150400.20.10.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="patterns-base-basesystem-20200124-150400.20.10.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:patterns-base-basesystem-20200124-150400.20.10.1">patterns-base-basesystem-20200124-150400.20.10.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="patterns-base-minimal_base-20200124-150400.20.10.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:patterns-base-minimal_base-20200124-150400.20.10.1">patterns-base-minimal_base-20200124-150400.20.10.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pcsc-lite-1.9.4-150400.3.2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:pcsc-lite-1.9.4-150400.3.2.1">pcsc-lite-1.9.4-150400.3.2.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="procps-3.3.17-150000.7.39.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:procps-3.3.17-150000.7.39.1">procps-3.3.17-150000.7.39.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python-instance-billing-flavor-check-0.0.6-150400.1.11.7" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:python-instance-billing-flavor-check-0.0.6-150400.1.11.7">python-instance-billing-flavor-check-0.0.6-150400.1.11.7 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-3.6.15-150300.10.65.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:python3-3.6.15-150300.10.65.2">python3-3.6.15-150300.10.65.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-base-3.6.15-150300.10.65.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:python3-base-3.6.15-150300.10.65.1">python3-base-3.6.15-150300.10.65.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-cssselect-1.0.3-150400.3.7.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:python3-cssselect-1.0.3-150400.3.7.4">python3-cssselect-1.0.3-150400.3.7.4 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-curses-3.6.15-150300.10.65.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:python3-curses-3.6.15-150300.10.65.2">python3-curses-3.6.15-150300.10.65.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-lxml-4.9.1-150500.3.4.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:python3-lxml-4.9.1-150500.3.4.3">python3-lxml-4.9.1-150500.3.4.3 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-requests-2.25.1-150300.3.12.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:python3-requests-2.25.1-150300.3.12.2">python3-requests-2.25.1-150300.3.12.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-solv-0.7.29-150400.3.22.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:python3-solv-0.7.29-150400.3.22.4">python3-solv-0.7.29-150400.3.22.4 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-urllib3-1.25.10-150300.4.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:python3-urllib3-1.25.10-150300.4.12.1">python3-urllib3-1.25.10-150300.4.12.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="resource-agents-4.12.0+git30.7fd7c8fa-150500.3.9.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:resource-agents-4.12.0+git30.7fd7c8fa-150500.3.9.2">resource-agents-4.12.0+git30.7fd7c8fa-150500.3.9.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby-solv-0.7.29-150400.3.22.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:ruby-solv-0.7.29-150400.3.22.4">ruby-solv-0.7.29-150400.3.22.4 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby2.5-rubygem-sass-3.7.4-150000.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:ruby2.5-rubygem-sass-3.7.4-150000.3.3.1">ruby2.5-rubygem-sass-3.7.4-150000.3.3.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="runc-1.1.13-150000.67.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:runc-1.1.13-150000.67.1">runc-1.1.13-150000.67.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="scap-security-guide-0.1.73-150000.1.83.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:scap-security-guide-0.1.73-150000.1.83.1">scap-security-guide-0.1.73-150000.1.83.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="shadow-4.8.1-150400.10.21.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:shadow-4.8.1-150400.10.21.1">shadow-4.8.1-150400.10.21.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="socat-1.8.0.0-150400.14.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:socat-1.8.0.0-150400.14.3.1">socat-1.8.0.0-150400.14.3.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="supportutils-3.1.30-150300.7.35.30.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:supportutils-3.1.30-150300.7.35.30.1">supportutils-3.1.30-150300.7.35.30.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suse-build-key-12.0-150000.8.49.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:suse-build-key-12.0-150000.8.49.2">suse-build-key-12.0-150000.8.49.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suse-module-tools-15.5.5-150500.3.12.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:suse-module-tools-15.5.5-150500.3.12.2">suse-module-tools-15.5.5-150500.3.12.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ng-1.11.0-150500.3.26.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:suseconnect-ng-1.11.0-150500.3.26.4">suseconnect-ng-1.11.0-150500.3.26.4 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ruby-bindings-1.11.0-150500.3.26.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:suseconnect-ruby-bindings-1.11.0-150500.3.26.4">suseconnect-ruby-bindings-1.11.0-150500.3.26.4 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-2.37.4-150500.9.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:util-linux-2.37.4-150500.9.11.1">util-linux-2.37.4-150500.9.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-systemd-2.37.4-150500.9.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:util-linux-systemd-2.37.4-150500.9.11.1">util-linux-systemd-2.37.4-150500.9.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="uuidd-2.37.4-150500.9.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:uuidd-2.37.4-150500.9.11.1">uuidd-2.37.4-150500.9.11.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wget-1.20.3-150000.3.20.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:wget-1.20.3-150000.3.20.1">wget-1.20.3-150000.3.20.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wicked-0.6.76-150500.3.33.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:wicked-0.6.76-150500.3.33.1">wicked-0.6.76-150500.3.33.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wicked-service-0.6.76-150500.3.33.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:wicked-service-0.6.76-150500.3.33.1">wicked-service-0.6.76-150500.3.33.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="xen-libs-4.17.4_04-150500.3.33.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:xen-libs-4.17.4_04-150500.3.33.1">xen-libs-4.17.4_04-150500.3.33.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="xfsprogs-5.13.0-150400.3.10.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:xfsprogs-5.13.0-150400.3.10.2">xfsprogs-5.13.0-150400.3.10.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="xkbcomp-1.4.1-150000.3.3.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:xkbcomp-1.4.1-150000.3.3.2">xkbcomp-1.4.1-150000.3.3.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-country-4.5.6-150500.3.3.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:yast2-country-4.5.6-150500.3.3.2">yast2-country-4.5.6-150500.3.3.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-country-data-4.5.6-150500.3.3.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:yast2-country-data-4.5.6-150500.3.3.2">yast2-country-data-4.5.6-150500.3.3.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-iscsi-client-4.5.9-150500.3.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:yast2-iscsi-client-4.5.9-150500.3.6.2">yast2-iscsi-client-4.5.9-150500.3.6.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-pkg-bindings-4.5.3-150500.3.7.17" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:yast2-pkg-bindings-4.5.3-150500.3.7.17">yast2-pkg-bindings-4.5.3-150500.3.7.17 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-registration-4.5.10-150500.3.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:yast2-registration-4.5.10-150500.3.6.2">yast2-registration-4.5.10-150500.3.6.2 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="zypper-1.14.73-150500.6.2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-x86-64:zypper-1.14.73-150500.6.2.1">zypper-1.14.73-150500.6.2.1 as a component of Public Cloud Image google/sles-sap-15-sp5-hardened-v20240808-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"/>
    </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">A NULL Pointer Dereference in match_at() in regexec.c in Oniguruma 6.9.2 allows attackers to potentially cause denial of service by providing a crafted regular expression. Oniguruma issues often affect Ruby, as well as common optional libraries for PHP and Rust.</Note>
    </Notes>
    <CVE>CVE-2019-13225</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>4.3</BaseScore>
        <Vector>AV:N/AC:M/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 aio_poll_complete_work of aio.c, there is a possible memory corruption due to a use after free. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-185125206References: Upstream kernel</Note>
    </Notes>
    <CVE>CVE-2021-39698</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>7.2</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:C/I:C/A:C</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was discovered in the Linux kernel for powerpc before 5.14.15. It allows a malicious KVM guest to crash the host, when the host is running on Power8, due to an arch/powerpc/kvm/book3s_hv_rmhandlers.S implementation bug in the handling of the SRR1 register values.</Note>
    </Notes>
    <CVE>CVE-2021-43056</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>4.9</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:N/I:N/A:C</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

staging: greybus: uart: fix tty use after free

User space can hold a tty open indefinitely and tty drivers must not
release the underlying structures until the last user is gone.

Switch to using the tty-port reference counter to manage the life time
of the greybus tty state to avoid use after free after a disconnect.</Note>
    </Notes>
    <CVE>CVE-2021-47358</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 soft lockup during fsstress

Below traces are observed during fsstress and system got hung.
[  130.698396] watchdog: BUG: soft lockup - CPU#6 stuck for 26s!</Note>
    </Notes>
    <CVE>CVE-2021-47359</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

binder: make sure fd closes complete

During BC_FREE_BUFFER processing, the BINDER_TYPE_FDA object
cleanup may close 1 or more fds. The close operations are
completed using the task work mechanism -- which means the thread
needs to return to userspace or the file object may never be
dereferenced -- which can lead to hung processes.

Force the binder thread back to userspace if an fd is closed during
BC_FREE_BUFFER handling.</Note>
    </Notes>
    <CVE>CVE-2021-47360</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nexthop: Fix division by zero while replacing a resilient group

The resilient nexthop group torture tests in fib_nexthop.sh exposed a
possible division by zero while replacing a resilient group [1]. The
division by zero occurs when the data path sees a resilient nexthop
group with zero buckets.

The tests replace a resilient nexthop group in a loop while traffic is
forwarded through it. The tests do not specify the number of buckets
while performing the replacement, resulting in the kernel allocating a
stub resilient table (i.e, 'struct nh_res_table') with zero buckets.

This table should never be visible to the data path, but the old nexthop
group (i.e., 'oldg') might still be used by the data path when the stub
table is assigned to it.

Fix this by only assigning the stub table to the old nexthop group after
making sure the group is no longer used by the data path.

Tested with fib_nexthops.sh:

Tests passed: 222
Tests failed:   0

[1]
 divide error: 0000 [#1] PREEMPT SMP KASAN
 CPU: 0 PID: 1850 Comm: ping Not tainted 5.14.0-custom-10271-ga86eb53057fe #1107
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014
 RIP: 0010:nexthop_select_path+0x2d2/0x1a80
[...]
 Call Trace:
  fib_select_multipath+0x79b/0x1530
  fib_select_path+0x8fb/0x1c10
  ip_route_output_key_hash_rcu+0x1198/0x2da0
  ip_route_output_key_hash+0x190/0x340
  ip_route_output_flow+0x21/0x120
  raw_sendmsg+0x91d/0x2e10
  inet_sendmsg+0x9e/0xe0
  __sys_sendto+0x23d/0x360
  __x64_sys_sendto+0xe1/0x1b0
  do_syscall_64+0x35/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae</Note>
    </Notes>
    <CVE>CVE-2021-47363</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

comedi: Fix memory leak in compat_insnlist()

`compat_insnlist()` handles the 32-bit version of the `COMEDI_INSNLIST`
ioctl (whenwhen `CONFIG_COMPAT` is enabled).  It allocates memory to
temporarily hold an array of `struct comedi_insn` converted from the
32-bit version in user space.  This memory is only being freed if there
is a fault while filling the array, otherwise it is leaked.

Add a call to `kfree()` to fix the leak.</Note>
    </Notes>
    <CVE>CVE-2021-47364</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

afs: Fix page leak

There's a loop in afs_extend_writeback() that adds extra pages to a write
we want to make to improve the efficiency of the writeback by making it
larger.  This loop stops, however, if we hit a page we can't write back
from immediately, but it doesn't get rid of the page ref we speculatively
acquired.

This was caused by the removal of the cleanup loop when the code switched
from using find_get_pages_contig() to xarray scanning as the latter only
gets a single page at a time, not a batch.

Fix this by putting the page on a ref on an early break from the loop.
Unfortunately, we can't just add that page to the pagevec we're employing
as we'll go through that and add those pages to the RPC call.

This was found by the generic/074 test.  It leaks ~4GiB of RAM each time it
is run - which can be observed with "top".</Note>
    </Notes>
    <CVE>CVE-2021-47365</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server

AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and
Linux's afs client switches between them when talking to a non-YFS server
if the read size, the file position or the sum of the two have the upper 32
bits set of the 64-bit value.

This is a problem, however, since the file position and length fields of
FS.FetchData are *signed* 32-bit values.

Fix this by capturing the capability bits obtained from the fileserver when
it's sent an FS.GetCapabilities RPC, rather than just discarding them, and
then picking out the VICED_CAPABILITY_64BITFILES flag.  This can then be
used to decide whether to use FS.FetchData or FS.FetchData64 - and also
FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to
switch on the parameter values.

This capabilities flag could also be used to limit the maximum size of the
file, but all servers must be checked for that.

Note that the issue does not exist with FS.StoreData - that uses *unsigned*
32-bit values.  It's also not a problem with Auristor servers as its
YFS.FetchData64 op uses unsigned 64-bit values.

This can be tested by cloning a git repo through an OpenAFS client to an
OpenAFS server and then doing "git status" on it from a Linux afs
client[1].  Provided the clone has a pack file that's in the 2G-4G range,
the git status will show errors like:

	error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index
	error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index

This can be observed in the server's FileLog with something like the
following appearing:

Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001
Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001
Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154
Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866
...
Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5

Note the file position of 18446744071815340032.  This is the requested file
position sign-extended.</Note>
    </Notes>
    <CVE>CVE-2021-47366</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix pages leaking when building skb in big mode

We try to use build_skb() if we had sufficient tailroom. But we forget
to release the unused pages chained via private in big mode which will
leak pages. Fixing this by release the pages after building the skb in
big mode.</Note>
    </Notes>
    <CVE>CVE-2021-47367</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

enetc: Fix illegal access when reading affinity_hint

irq_set_affinity_hit() stores a reference to the cpumask_t
parameter in the irq descriptor, and that reference can be
accessed later from irq_affinity_hint_proc_show(). Since
the cpu_mask parameter passed to irq_set_affinity_hit() has
only temporary storage (it's on the stack memory), later
accesses to it are illegal. Thus reads from the corresponding
procfs affinity_hint file can result in paging request oops.

The issue is fixed by the get_cpu_mask() helper, which provides
a permanent storage for the cpumask_t parameter.</Note>
    </Notes>
    <CVE>CVE-2021-47368</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mptcp: ensure tx skbs always have the MPTCP ext

Due to signed/unsigned comparison, the expression:

	info-&gt;size_goal - skb-&gt;len &gt; 0

evaluates to true when the size goal is smaller than the
skb size. That results in lack of tx cache refill, so that
the skb allocated by the core TCP code lacks the required
MPTCP skb extensions.

Due to the above, syzbot is able to trigger the following WARN_ON():

WARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366
Modules linked in:
CPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366
Code: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 &lt;0f&gt; 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9
RSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216
RAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000
RDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003
RBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280
R13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0
FS:  00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 __mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol.c:1547
 mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003
 release_sock+0xb4/0x1b0 net/core/sock.c:3206
 sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145
 mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749
 inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643
 sock_sendmsg_nosec net/socket.c:704 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:724
 sock_write_iter+0x2a0/0x3e0 net/socket.c:1057
 call_write_iter include/linux/fs.h:2163 [inline]
 new_sync_write+0x40b/0x640 fs/read_write.c:507
 vfs_write+0x7cf/0xae0 fs/read_write.c:594
 ksys_write+0x1ee/0x250 fs/read_write.c:647
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x4665f9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9
RDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003
RBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038
R13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000

Fix the issue rewriting the relevant expression to avoid
sign-related problems - note: size_goal is always &gt;= 0.

Additionally, ensure that the skb in the tx cache always carries
the relevant extension.</Note>
    </Notes>
    <CVE>CVE-2021-47370</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nexthop: Fix memory leaks in nexthop notification chain listeners

syzkaller discovered memory leaks [1] that can be reduced to the
following commands:

 # ip nexthop add id 1 blackhole
 # devlink dev reload pci/0000:06:00.0

As part of the reload flow, mlxsw will unregister its netdevs and then
unregister from the nexthop notification chain. Before unregistering
from the notification chain, mlxsw will receive delete notifications for
nexthop objects using netdevs registered by mlxsw or their uppers. mlxsw
will not receive notifications for nexthops using netdevs that are not
dismantled as part of the reload flow. For example, the blackhole
nexthop above that internally uses the loopback netdev as its nexthop
device.

One way to fix this problem is to have listeners flush their nexthop
tables after unregistering from the notification chain. This is
error-prone as evident by this patch and also not symmetric with the
registration path where a listener receives a dump of all the existing
nexthops.

Therefore, fix this problem by replaying delete notifications for the
listener being unregistered. This is symmetric to the registration path
and also consistent with the netdev notification chain.

The above means that unregister_nexthop_notifier(), like
register_nexthop_notifier(), will have to take RTNL in order to iterate
over the existing nexthops and that any callers of the function cannot
hold RTNL. This is true for mlxsw and netdevsim, but not for the VXLAN
driver. To avoid a deadlock, change the latter to unregister its nexthop
listener without holding RTNL, making it symmetric to the registration
path.

[1]
unreferenced object 0xffff88806173d600 (size 512):
  comm "syz-executor.0", pid 1290, jiffies 4295583142 (age 143.507s)
  hex dump (first 32 bytes):
    41 9d 1e 60 80 88 ff ff 08 d6 73 61 80 88 ff ff  A..`......sa....
    08 d6 73 61 80 88 ff ff 01 00 00 00 00 00 00 00  ..sa............
  backtrace:
    [&lt;ffffffff81a6b576&gt;] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]
    [&lt;ffffffff81a6b576&gt;] slab_post_alloc_hook+0x96/0x490 mm/slab.h:522
    [&lt;ffffffff81a716d3&gt;] slab_alloc_node mm/slub.c:3206 [inline]
    [&lt;ffffffff81a716d3&gt;] slab_alloc mm/slub.c:3214 [inline]
    [&lt;ffffffff81a716d3&gt;] kmem_cache_alloc_trace+0x163/0x370 mm/slub.c:3231
    [&lt;ffffffff82e8681a&gt;] kmalloc include/linux/slab.h:591 [inline]
    [&lt;ffffffff82e8681a&gt;] kzalloc include/linux/slab.h:721 [inline]
    [&lt;ffffffff82e8681a&gt;] mlxsw_sp_nexthop_obj_group_create drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:4918 [inline]
    [&lt;ffffffff82e8681a&gt;] mlxsw_sp_nexthop_obj_new drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5054 [inline]
    [&lt;ffffffff82e8681a&gt;] mlxsw_sp_nexthop_obj_event+0x59a/0x2910 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5239
    [&lt;ffffffff813ef67d&gt;] notifier_call_chain+0xbd/0x210 kernel/notifier.c:83
    [&lt;ffffffff813f0662&gt;] blocking_notifier_call_chain kernel/notifier.c:318 [inline]
    [&lt;ffffffff813f0662&gt;] blocking_notifier_call_chain+0x72/0xa0 kernel/notifier.c:306
    [&lt;ffffffff8384b9c6&gt;] call_nexthop_notifiers+0x156/0x310 net/ipv4/nexthop.c:244
    [&lt;ffffffff83852bd8&gt;] insert_nexthop net/ipv4/nexthop.c:2336 [inline]
    [&lt;ffffffff83852bd8&gt;] nexthop_add net/ipv4/nexthop.c:2644 [inline]
    [&lt;ffffffff83852bd8&gt;] rtm_new_nexthop+0x14e8/0x4d10 net/ipv4/nexthop.c:2913
    [&lt;ffffffff833e9a78&gt;] rtnetlink_rcv_msg+0x448/0xbf0 net/core/rtnetlink.c:5572
    [&lt;ffffffff83608703&gt;] netlink_rcv_skb+0x173/0x480 net/netlink/af_netlink.c:2504
    [&lt;ffffffff833de032&gt;] rtnetlink_rcv+0x22/0x30 net/core/rtnetlink.c:5590
    [&lt;ffffffff836069de&gt;] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
    [&lt;ffffffff836069de&gt;] netlink_unicast+0x5ae/0x7f0 net/netlink/af_netlink.c:1340
    [&lt;ffffffff83607501&gt;] netlink_sendmsg+0x8e1/0xe30 net/netlink/af_netlink.c:1929
    [&lt;ffffffff832fde84&gt;] sock_sendmsg_nosec net/socket.c:704 [inline
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47371</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

irqchip/gic-v3-its: Fix potential VPE leak on error

In its_vpe_irq_domain_alloc, when its_vpe_init() returns an error,
there is an off-by-one in the number of VPEs to be freed.

Fix it by simply passing the number of VPEs allocated, which is the
index of the loop iterating over the VPEs.

[maz: fixed commit message]</Note>
    </Notes>
    <CVE>CVE-2021-47373</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

dma-debug: prevent an error message from causing runtime problems

For some drivers, that use the DMA API. This error message can be reached
several millions of times per second, causing spam to the kernel's printk
buffer and bringing the CPU usage up to 100% (so, it should be rate
limited). However, since there is at least one driver that is in the
mainline and suffers from the error condition, it is more useful to
err_printk() here instead of just rate limiting the error message (in hopes
that it will make it easier for other drivers that suffer from this issue
to be spotted).</Note>
    </Notes>
    <CVE>CVE-2021-47374</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Add oversize check before call kvcalloc()

Commit 7661809d493b ("mm: don't allow oversized kvmalloc() calls") add the
oversize check. When the allocation is larger than what kmalloc() supports,
the following warning triggered:

WARNING: CPU: 0 PID: 8408 at mm/util.c:597 kvmalloc_node+0x108/0x110 mm/util.c:597
Modules linked in:
CPU: 0 PID: 8408 Comm: syz-executor221 Not tainted 5.14.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:kvmalloc_node+0x108/0x110 mm/util.c:597
Call Trace:
 kvmalloc include/linux/mm.h:806 [inline]
 kvmalloc_array include/linux/mm.h:824 [inline]
 kvcalloc include/linux/mm.h:829 [inline]
 check_btf_line kernel/bpf/verifier.c:9925 [inline]
 check_btf_info kernel/bpf/verifier.c:10049 [inline]
 bpf_check+0xd634/0x150d0 kernel/bpf/verifier.c:13759
 bpf_prog_load kernel/bpf/syscall.c:2301 [inline]
 __sys_bpf+0x11181/0x126e0 kernel/bpf/syscall.c:4587
 __do_sys_bpf kernel/bpf/syscall.c:4691 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:4689 [inline]
 __x64_sys_bpf+0x78/0x90 kernel/bpf/syscall.c:4689
 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+0x44/0xae</Note>
    </Notes>
    <CVE>CVE-2021-47376</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

HID: amd_sfh: Fix potential NULL pointer dereference

devm_add_action_or_reset() can suddenly invoke amd_mp2_pci_remove() at
registration that will cause NULL pointer dereference since
corresponding data is not initialized yet. The patch moves
initialization of data before devm_add_action_or_reset().

Found by Linux Driver Verification project (linuxtesting.org).

[jkosina@suse.cz: rebase]</Note>
    </Notes>
    <CVE>CVE-2021-47380</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ASoC: SOF: Fix DSP oops stack dump output contents

Fix @buf arg given to hex_dump_to_buffer() and stack address used
in dump error output.</Note>
    </Notes>
    <CVE>CVE-2021-47381</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field

If driver read tmp value sufficient for
(tmp &amp; 0x08) &amp;&amp; (!(tmp &amp; 0x80)) &amp;&amp; ((tmp &amp; 0x7) == ((tmp &gt;&gt; 4) &amp; 0x7))
from device then Null pointer dereference occurs.
(It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers)
Also lm75[] does not serve a purpose anymore after switching to
devm_i2c_new_dummy_device() in w83791d_detect_subclients().

The patch fixes possible NULL pointer dereference by removing lm75[].

Found by Linux Driver Verification project (linuxtesting.org).

[groeck: Dropped unnecessary continuation lines, fixed multi-line alignments]</Note>
    </Notes>
    <CVE>CVE-2021-47384</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: (w83792d) Fix NULL pointer dereference by removing unnecessary structure field

If driver read val value sufficient for
(val &amp; 0x08) &amp;&amp; (!(val &amp; 0x80)) &amp;&amp; ((val &amp; 0x7) == ((val &gt;&gt; 4) &amp; 0x7))
from device then Null pointer dereference occurs.
(It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers)
Also lm75[] does not serve a purpose anymore after switching to
devm_i2c_new_dummy_device() in w83791d_detect_subclients().

The patch fixes possible NULL pointer dereference by removing lm75[].

Found by Linux Driver Verification project (linuxtesting.org).

[groeck: Dropped unnecessary continuation lines, fixed multipline alignment]</Note>
    </Notes>
    <CVE>CVE-2021-47385</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: (w83791d) Fix NULL pointer dereference by removing unnecessary structure field

If driver read val value sufficient for
(val &amp; 0x08) &amp;&amp; (!(val &amp; 0x80)) &amp;&amp; ((val &amp; 0x7) == ((val &gt;&gt; 4) &amp; 0x7))
from device then Null pointer dereference occurs.
(It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers)
Also lm75[] does not serve a purpose anymore after switching to
devm_i2c_new_dummy_device() in w83791d_detect_subclients().

The patch fixes possible NULL pointer dereference by removing lm75[].

Found by Linux Driver Verification project (linuxtesting.org).

[groeck: Dropped unnecessary continuation lines, fixed multi-line alignment]</Note>
    </Notes>
    <CVE>CVE-2021-47386</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cpufreq: schedutil: Use kobject release() method to free sugov_tunables

The struct sugov_tunables is protected by the kobject, so we can't free
it directly. Otherwise we would get a call trace like this:
  ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x30
  WARNING: CPU: 3 PID: 720 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100
  Modules linked in:
  CPU: 3 PID: 720 Comm: a.sh Tainted: G        W         5.14.0-rc1-next-20210715-yocto-standard+ #507
  Hardware name: Marvell OcteonTX CN96XX board (DT)
  pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--)
  pc : debug_print_object+0xb8/0x100
  lr : debug_print_object+0xb8/0x100
  sp : ffff80001ecaf910
  x29: ffff80001ecaf910 x28: ffff00011b10b8d0 x27: ffff800011043d80
  x26: ffff00011a8f0000 x25: ffff800013cb3ff0 x24: 0000000000000000
  x23: ffff80001142aa68 x22: ffff800011043d80 x21: ffff00010de46f20
  x20: ffff800013c0c520 x19: ffff800011d8f5b0 x18: 0000000000000010
  x17: 6e6968207473696c x16: 5f72656d6974203a x15: 6570797420746365
  x14: 6a626f2029302065 x13: 303378302f307830 x12: 2b6e665f72656d69
  x11: ffff8000124b1560 x10: ffff800012331520 x9 : ffff8000100ca6b0
  x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 0000000000000001
  x5 : ffff800011d8c000 x4 : ffff800011d8c740 x3 : 0000000000000000
  x2 : ffff0001108301c0 x1 : ab3c90eedf9c0f00 x0 : 0000000000000000
  Call trace:
   debug_print_object+0xb8/0x100
   __debug_check_no_obj_freed+0x1c0/0x230
   debug_check_no_obj_freed+0x20/0x88
   slab_free_freelist_hook+0x154/0x1c8
   kfree+0x114/0x5d0
   sugov_exit+0xbc/0xc0
   cpufreq_exit_governor+0x44/0x90
   cpufreq_set_policy+0x268/0x4a8
   store_scaling_governor+0xe0/0x128
   store+0xc0/0xf0
   sysfs_kf_write+0x54/0x80
   kernfs_fop_write_iter+0x128/0x1c0
   new_sync_write+0xf0/0x190
   vfs_write+0x2d4/0x478
   ksys_write+0x74/0x100
   __arm64_sys_write+0x24/0x30
   invoke_syscall.constprop.0+0x54/0xe0
   do_el0_svc+0x64/0x158
   el0_svc+0x2c/0xb0
   el0t_64_sync_handler+0xb0/0xb8
   el0t_64_sync+0x198/0x19c
  irq event stamp: 5518
  hardirqs last  enabled at (5517): [&lt;ffff8000100cbd7c&gt;] console_unlock+0x554/0x6c8
  hardirqs last disabled at (5518): [&lt;ffff800010fc0638&gt;] el1_dbg+0x28/0xa0
  softirqs last  enabled at (5504): [&lt;ffff8000100106e0&gt;] __do_softirq+0x4d0/0x6c0
  softirqs last disabled at (5483): [&lt;ffff800010049548&gt;] irq_exit+0x1b0/0x1b8

So split the original sugov_tunables_free() into two functions,
sugov_clear_global_tunables() is just used to clear the global_tunables
and the new sugov_tunables_free() is used as kobj_type::release to
release the sugov_tunables safely.</Note>
    </Notes>
    <CVE>CVE-2021-47387</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mac80211: fix use-after-free in CCMP/GCMP RX

When PN checking is done in mac80211, for fragmentation we need
to copy the PN to the RX struct so we can later use it to do a
comparison, since commit bf30ca922a0c ("mac80211: check defrag
PN against current frame").

Unfortunately, in that commit I used the 'hdr' variable without
it being necessarily valid, so use-after-free could occur if it
was necessary to reallocate (parts of) the frame.

Fix this by reloading the variable after the code that results
in the reallocations, if any.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=214401.</Note>
    </Notes>
    <CVE>CVE-2021-47388</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix missing sev_decommission in sev_receive_start

DECOMMISSION the current SEV context if binding an ASID fails after
RECEIVE_START.  Per AMD's SEV API, RECEIVE_START generates a new guest
context and thus needs to be paired with DECOMMISSION:

     The RECEIVE_START command is the only command other than the LAUNCH_START
     command that generates a new guest context and guest handle.

The missing DECOMMISSION can result in subsequent SEV launch failures,
as the firmware leaks memory and might not able to allocate more SEV
guest contexts in the future.

Note, LAUNCH_START suffered the same bug, but was previously fixed by
commit 934002cd660b ("KVM: SVM: Call SEV Guest Decommission if ASID
binding fails").</Note>
    </Notes>
    <CVE>CVE-2021-47389</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix stack-out-of-bounds memory access from ioapic_write_indirect()

KASAN reports the following issue:

 BUG: KASAN: stack-out-of-bounds in kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
 Read of size 8 at addr ffffc9001364f638 by task qemu-kvm/4798

 CPU: 0 PID: 4798 Comm: qemu-kvm Tainted: G               X --------- ---
 Hardware name: AMD Corporation DAYTONA_X/DAYTONA_X, BIOS RYM0081C 07/13/2020
 Call Trace:
  dump_stack+0xa5/0xe6
  print_address_description.constprop.0+0x18/0x130
  ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
  __kasan_report.cold+0x7f/0x114
  ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
  kasan_report+0x38/0x50
  kasan_check_range+0xf5/0x1d0
  kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
  kvm_make_scan_ioapic_request_mask+0x84/0xc0 [kvm]
  ? kvm_arch_exit+0x110/0x110 [kvm]
  ? sched_clock+0x5/0x10
  ioapic_write_indirect+0x59f/0x9e0 [kvm]
  ? static_obj+0xc0/0xc0
  ? __lock_acquired+0x1d2/0x8c0
  ? kvm_ioapic_eoi_inject_work+0x120/0x120 [kvm]

The problem appears to be that 'vcpu_bitmap' is allocated as a single long
on stack and it should really be KVM_MAX_VCPUS long. We also seem to clear
the lower 16 bits of it with bitmap_zero() for no particular reason (my
guess would be that 'bitmap' and 'vcpu_bitmap' variables in
kvm_bitmap_or_dest_vcpus() caused the confusion: while the later is indeed
16-bit long, the later should accommodate all possible vCPUs).</Note>
    </Notes>
    <CVE>CVE-2021-47390</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

RDMA/cma: Fix listener leak in rdma_cma_listen_on_all() failure

If cma_listen_on_all() fails it leaves the per-device ID still on the
listen_list but the state is not set to RDMA_CM_ADDR_BOUND.

When the cmid is eventually destroyed cma_cancel_listens() is not called
due to the wrong state, however the per-device IDs are still holding the
refcount preventing the ID from being destroyed, thus deadlocking:

 task:rping state:D stack:   0 pid:19605 ppid: 47036 flags:0x00000084
 Call Trace:
  __schedule+0x29a/0x780
  ? free_unref_page_commit+0x9b/0x110
  schedule+0x3c/0xa0
  schedule_timeout+0x215/0x2b0
  ? __flush_work+0x19e/0x1e0
  wait_for_completion+0x8d/0xf0
  _destroy_id+0x144/0x210 [rdma_cm]
  ucma_close_id+0x2b/0x40 [rdma_ucm]
  __destroy_id+0x93/0x2c0 [rdma_ucm]
  ? __xa_erase+0x4a/0xa0
  ucma_destroy_id+0x9a/0x120 [rdma_ucm]
  ucma_write+0xb8/0x130 [rdma_ucm]
  vfs_write+0xb4/0x250
  ksys_write+0xb5/0xd0
  ? syscall_trace_enter.isra.19+0x123/0x190
  do_syscall_64+0x33/0x40
  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Ensure that cma_listen_on_all() atomically unwinds its action under the
lock during error.</Note>
    </Notes>
    <CVE>CVE-2021-47392</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs

Fan speed minimum can be enforced from sysfs. For example, setting
current fan speed to 20 is used to enforce fan speed to be at 100%
speed, 19 - to be not below 90% speed, etcetera. This feature provides
ability to limit fan speed according to some system wise
considerations, like absence of some replaceable units or high system
ambient temperature.

Request for changing fan minimum speed is configuration request and can
be set only through 'sysfs' write procedure. In this situation value of
argument 'state' is above nominal fan speed maximum.

Return non-zero code in this case to avoid
thermal_cooling_device_stats_update() call, because in this case
statistics update violates thermal statistics table range.
The issues is observed in case kernel is configured with option
CONFIG_THERMAL_STATISTICS.

Here is the trace from KASAN:
[  159.506659] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x7d/0xb0
[  159.516016] Read of size 4 at addr ffff888116163840 by task hw-management.s/7444
[  159.545625] Call Trace:
[  159.548366]  dump_stack+0x92/0xc1
[  159.552084]  ? thermal_cooling_device_stats_update+0x7d/0xb0
[  159.635869]  thermal_zone_device_update+0x345/0x780
[  159.688711]  thermal_zone_device_set_mode+0x7d/0xc0
[  159.694174]  mlxsw_thermal_modules_init+0x48f/0x590 [mlxsw_core]
[  159.700972]  ? mlxsw_thermal_set_cur_state+0x5a0/0x5a0 [mlxsw_core]
[  159.731827]  mlxsw_thermal_init+0x763/0x880 [mlxsw_core]
[  160.070233] RIP: 0033:0x7fd995909970
[  160.074239] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ..
[  160.095242] RSP: 002b:00007fff54f5d938 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[  160.103722] RAX: ffffffffffffffda RBX: 0000000000000013 RCX: 00007fd995909970
[  160.111710] RDX: 0000000000000013 RSI: 0000000001906008 RDI: 0000000000000001
[  160.119699] RBP: 0000000001906008 R08: 00007fd995bc9760 R09: 00007fd996210700
[  160.127687] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000013
[  160.135673] R13: 0000000000000001 R14: 00007fd995bc8600 R15: 0000000000000013
[  160.143671]
[  160.145338] Allocated by task 2924:
[  160.149242]  kasan_save_stack+0x19/0x40
[  160.153541]  __kasan_kmalloc+0x7f/0xa0
[  160.157743]  __kmalloc+0x1a2/0x2b0
[  160.161552]  thermal_cooling_device_setup_sysfs+0xf9/0x1a0
[  160.167687]  __thermal_cooling_device_register+0x1b5/0x500
[  160.173833]  devm_thermal_of_cooling_device_register+0x60/0xa0
[  160.180356]  mlxreg_fan_probe+0x474/0x5e0 [mlxreg_fan]
[  160.248140]
[  160.249807] The buggy address belongs to the object at ffff888116163400
[  160.249807]  which belongs to the cache kmalloc-1k of size 1024
[  160.263814] The buggy address is located 64 bytes to the right of
[  160.263814]  1024-byte region [ffff888116163400, ffff888116163800)
[  160.277536] The buggy address belongs to the page:
[  160.282898] page:0000000012275840 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888116167000 pfn:0x116160
[  160.294872] head:0000000012275840 order:3 compound_mapcount:0 compound_pincount:0
[  160.303251] flags: 0x200000000010200(slab|head|node=0|zone=2)
[  160.309694] raw: 0200000000010200 ffffea00046f7208 ffffea0004928208 ffff88810004dbc0
[  160.318367] raw: ffff888116167000 00000000000a0006 00000001ffffffff 0000000000000000
[  160.327033] page dumped because: kasan: bad access detected
[  160.333270]
[  160.334937] Memory state around the buggy address:
[  160.356469] &gt;ffff888116163800: fc ..</Note>
    </Notes>
    <CVE>CVE-2021-47393</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: unlink table before deleting it

syzbot reports following UAF:
BUG: KASAN: use-after-free in memcmp+0x18f/0x1c0 lib/string.c:955
 nla_strcmp+0xf2/0x130 lib/nlattr.c:836
 nft_table_lookup.part.0+0x1a2/0x460 net/netfilter/nf_tables_api.c:570
 nft_table_lookup net/netfilter/nf_tables_api.c:4064 [inline]
 nf_tables_getset+0x1b3/0x860 net/netfilter/nf_tables_api.c:4064
 nfnetlink_rcv_msg+0x659/0x13f0 net/netfilter/nfnetlink.c:285
 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504

Problem is that all get operations are lockless, so the commit_mutex
held by nft_rcv_nl_event() isn't enough to stop a parallel GET request
from doing read-accesses to the table object even after synchronize_rcu().

To avoid this, unlink the table first and store the table objects in
on-stack scratch space.</Note>
    </Notes>
    <CVE>CVE-2021-47394</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mac80211: limit injected vht mcs/nss in ieee80211_parse_tx_radiotap

Limit max values for vht mcs and nss in ieee80211_parse_tx_radiotap
routine in order to fix the following warning reported by syzbot:

WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]
WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244
Modules linked in:
CPU: 0 PID: 10717 Comm: syz-executor.5 Not tainted 5.14.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]
RIP: 0010:ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244
RSP: 0018:ffffc9000186f3e8 EFLAGS: 00010216
RAX: 0000000000000618 RBX: ffff88804ef76500 RCX: ffffc900143a5000
RDX: 0000000000040000 RSI: ffffffff888f478e RDI: 0000000000000003
RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000100
R10: ffffffff888f46f9 R11: 0000000000000000 R12: 00000000fffffff8
R13: ffff88804ef7653c R14: 0000000000000001 R15: 0000000000000004
FS:  00007fbf5718f700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2de23000 CR3: 000000006a671000 CR4: 00000000001506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
Call Trace:
 ieee80211_monitor_select_queue+0xa6/0x250 net/mac80211/iface.c:740
 netdev_core_pick_tx+0x169/0x2e0 net/core/dev.c:4089
 __dev_queue_xmit+0x6f9/0x3710 net/core/dev.c:4165
 __bpf_tx_skb net/core/filter.c:2114 [inline]
 __bpf_redirect_no_mac net/core/filter.c:2139 [inline]
 __bpf_redirect+0x5ba/0xd20 net/core/filter.c:2162
 ____bpf_clone_redirect net/core/filter.c:2429 [inline]
 bpf_clone_redirect+0x2ae/0x420 net/core/filter.c:2401
 bpf_prog_eeb6f53a69e5c6a2+0x59/0x234
 bpf_dispatcher_nop_func include/linux/bpf.h:717 [inline]
 __bpf_prog_run include/linux/filter.h:624 [inline]
 bpf_prog_run include/linux/filter.h:631 [inline]
 bpf_test_run+0x381/0xa30 net/bpf/test_run.c:119
 bpf_prog_test_run_skb+0xb84/0x1ee0 net/bpf/test_run.c:663
 bpf_prog_test_run kernel/bpf/syscall.c:3307 [inline]
 __sys_bpf+0x2137/0x5df0 kernel/bpf/syscall.c:4605
 __do_sys_bpf kernel/bpf/syscall.c:4691 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:4689 [inline]
 __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x4665f9</Note>
    </Notes>
    <CVE>CVE-2021-47395</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-hwsim: fix late beacon hrtimer handling

Thomas explained in https://lore.kernel.org/r/87mtoeb4hb.ffs@tglx
that our handling of the hrtimer here is wrong: If the timer fires
late (e.g. due to vCPU scheduling, as reported by Dmitry/syzbot)
then it tries to actually rearm the timer at the next deadline,
which might be in the past already:

 1          2          3          N          N+1
 |          |          |   ...    |          |

 ^ intended to fire here (1)
            ^ next deadline here (2)
                                      ^ actually fired here

The next time it fires, it's later, but will still try to schedule
for the next deadline (now 3), etc. until it catches up with N,
but that might take a long time, causing stalls etc.

Now, all of this is simulation, so we just have to fix it, but
note that the behaviour is wrong even per spec, since there's no
value then in sending all those beacons unaligned - they should be
aligned to the TBTT (1, 2, 3, ... in the picture), and if we're a
bit (or a lot) late, then just resume at that point.

Therefore, change the code to use hrtimer_forward_now() which will
ensure that the next firing of the timer would be at N+1 (in the
picture), i.e. the next interval point after the current time.</Note>
    </Notes>
    <CVE>CVE-2021-47396</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/hfi1: Fix kernel pointer leak

Pointers should be printed with %p or %px rather than cast to 'unsigned
long long' and printed with %llx.  Change %llx to %p to print the secured
pointer.</Note>
    </Notes>
    <CVE>CVE-2021-47398</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ixgbe: Fix NULL pointer dereference in ixgbe_xdp_setup

The ixgbe driver currently generates a NULL pointer dereference with
some machine (online cpus &lt; 63). This is due to the fact that the
maximum value of num_xdp_queues is nr_cpu_ids. Code is in
"ixgbe_set_rss_queues"".

Here's how the problem repeats itself:
Some machine (online cpus &lt; 63), And user set num_queues to 63 through
ethtool. Code is in the "ixgbe_set_channels",
	adapter-&gt;ring_feature[RING_F_FDIR].limit = count;

It becomes 63.

When user use xdp, "ixgbe_set_rss_queues" will set queues num.
	adapter-&gt;num_rx_queues = rss_i;
	adapter-&gt;num_tx_queues = rss_i;
	adapter-&gt;num_xdp_queues = ixgbe_xdp_queues(adapter);

And rss_i's value is from
	f = &amp;adapter-&gt;ring_feature[RING_F_FDIR];
	rss_i = f-&gt;indices = f-&gt;limit;

So "num_rx_queues" &gt; "num_xdp_queues", when run to "ixgbe_xdp_setup",
	for (i = 0; i &lt; adapter-&gt;num_rx_queues; i++)
		if (adapter-&gt;xdp_ring[i]-&gt;xsk_umem)

It leads to panic.

Call trace:
[exception RIP: ixgbe_xdp+368]
RIP: ffffffffc02a76a0  RSP: ffff9fe16202f8d0  RFLAGS: 00010297
RAX: 0000000000000000  RBX: 0000000000000020  RCX: 0000000000000000
RDX: 0000000000000000  RSI: 000000000000001c  RDI: ffffffffa94ead90
RBP: ffff92f8f24c0c18   R8: 0000000000000000   R9: 0000000000000000
R10: ffff9fe16202f830  R11: 0000000000000000  R12: ffff92f8f24c0000
R13: ffff9fe16202fc01  R14: 000000000000000a  R15: ffffffffc02a7530
ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 7 [ffff9fe16202f8f0] dev_xdp_install at ffffffffa89fbbcc
 8 [ffff9fe16202f920] dev_change_xdp_fd at ffffffffa8a08808
 9 [ffff9fe16202f960] do_setlink at ffffffffa8a20235
10 [ffff9fe16202fa88] rtnl_setlink at ffffffffa8a20384
11 [ffff9fe16202fc78] rtnetlink_rcv_msg at ffffffffa8a1a8dd
12 [ffff9fe16202fcf0] netlink_rcv_skb at ffffffffa8a717eb
13 [ffff9fe16202fd40] netlink_unicast at ffffffffa8a70f88
14 [ffff9fe16202fd80] netlink_sendmsg at ffffffffa8a71319
15 [ffff9fe16202fdf0] sock_sendmsg at ffffffffa89df290
16 [ffff9fe16202fe08] __sys_sendto at ffffffffa89e19c8
17 [ffff9fe16202ff30] __x64_sys_sendto at ffffffffa89e1a64
18 [ffff9fe16202ff38] do_syscall_64 at ffffffffa84042b9
19 [ffff9fe16202ff50] entry_SYSCALL_64_after_hwframe at ffffffffa8c0008c

So I fix ixgbe_max_channels so that it will not allow a setting of queues
to be higher than the num_online_cpus(). And when run to ixgbe_xdp_setup,
take the smaller value of num_rx_queues and num_xdp_queues.</Note>
    </Notes>
    <CVE>CVE-2021-47399</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: flower: protect fl_walk() with rcu

Patch that refactored fl_walk() to use idr_for_each_entry_continue_ul()
also removed rcu protection of individual filters which causes following
use-after-free when filter is deleted concurrently. Fix fl_walk() to obtain
rcu read lock while iterating and taking the filter reference and temporary
release the lock while calling arg-&gt;fn() callback that can sleep.

KASAN trace:

[  352.773640] ==================================================================
[  352.775041] BUG: KASAN: use-after-free in fl_walk+0x159/0x240 [cls_flower]
[  352.776304] Read of size 4 at addr ffff8881c8251480 by task tc/2987

[  352.777862] CPU: 3 PID: 2987 Comm: tc Not tainted 5.15.0-rc2+ #2
[  352.778980] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
[  352.781022] Call Trace:
[  352.781573]  dump_stack_lvl+0x46/0x5a
[  352.782332]  print_address_description.constprop.0+0x1f/0x140
[  352.783400]  ? fl_walk+0x159/0x240 [cls_flower]
[  352.784292]  ? fl_walk+0x159/0x240 [cls_flower]
[  352.785138]  kasan_report.cold+0x83/0xdf
[  352.785851]  ? fl_walk+0x159/0x240 [cls_flower]
[  352.786587]  kasan_check_range+0x145/0x1a0
[  352.787337]  fl_walk+0x159/0x240 [cls_flower]
[  352.788163]  ? fl_put+0x10/0x10 [cls_flower]
[  352.789007]  ? __mutex_unlock_slowpath.constprop.0+0x220/0x220
[  352.790102]  tcf_chain_dump+0x231/0x450
[  352.790878]  ? tcf_chain_tp_delete_empty+0x170/0x170
[  352.791833]  ? __might_sleep+0x2e/0xc0
[  352.792594]  ? tfilter_notify+0x170/0x170
[  352.793400]  ? __mutex_unlock_slowpath.constprop.0+0x220/0x220
[  352.794477]  tc_dump_tfilter+0x385/0x4b0
[  352.795262]  ? tc_new_tfilter+0x1180/0x1180
[  352.796103]  ? __mod_node_page_state+0x1f/0xc0
[  352.796974]  ? __build_skb_around+0x10e/0x130
[  352.797826]  netlink_dump+0x2c0/0x560
[  352.798563]  ? netlink_getsockopt+0x430/0x430
[  352.799433]  ? __mutex_unlock_slowpath.constprop.0+0x220/0x220
[  352.800542]  __netlink_dump_start+0x356/0x440
[  352.801397]  rtnetlink_rcv_msg+0x3ff/0x550
[  352.802190]  ? tc_new_tfilter+0x1180/0x1180
[  352.802872]  ? rtnl_calcit.isra.0+0x1f0/0x1f0
[  352.803668]  ? tc_new_tfilter+0x1180/0x1180
[  352.804344]  ? _copy_from_iter_nocache+0x800/0x800
[  352.805202]  ? kasan_set_track+0x1c/0x30
[  352.805900]  netlink_rcv_skb+0xc6/0x1f0
[  352.806587]  ? rht_deferred_worker+0x6b0/0x6b0
[  352.807455]  ? rtnl_calcit.isra.0+0x1f0/0x1f0
[  352.808324]  ? netlink_ack+0x4d0/0x4d0
[  352.809086]  ? netlink_deliver_tap+0x62/0x3d0
[  352.809951]  netlink_unicast+0x353/0x480
[  352.810744]  ? netlink_attachskb+0x430/0x430
[  352.811586]  ? __alloc_skb+0xd7/0x200
[  352.812349]  netlink_sendmsg+0x396/0x680
[  352.813132]  ? netlink_unicast+0x480/0x480
[  352.813952]  ? __import_iovec+0x192/0x210
[  352.814759]  ? netlink_unicast+0x480/0x480
[  352.815580]  sock_sendmsg+0x6c/0x80
[  352.816299]  ____sys_sendmsg+0x3a5/0x3c0
[  352.817096]  ? kernel_sendmsg+0x30/0x30
[  352.817873]  ? __ia32_sys_recvmmsg+0x150/0x150
[  352.818753]  ___sys_sendmsg+0xd8/0x140
[  352.819518]  ? sendmsg_copy_msghdr+0x110/0x110
[  352.820402]  ? ___sys_recvmsg+0xf4/0x1a0
[  352.821110]  ? __copy_msghdr_from_user+0x260/0x260
[  352.821934]  ? _raw_spin_lock+0x81/0xd0
[  352.822680]  ? __handle_mm_fault+0xef3/0x1b20
[  352.823549]  ? rb_insert_color+0x2a/0x270
[  352.824373]  ? copy_page_range+0x16b0/0x16b0
[  352.825209]  ? perf_event_update_userpage+0x2d0/0x2d0
[  352.826190]  ? __fget_light+0xd9/0xf0
[  352.826941]  __sys_sendmsg+0xb3/0x130
[  352.827613]  ? __sys_sendmsg_sock+0x20/0x20
[  352.828377]  ? do_user_addr_fault+0x2c5/0x8a0
[  352.829184]  ? fpregs_assert_state_consistent+0x52/0x60
[  352.830001]  ? exit_to_user_mode_prepare+0x32/0x160
[  352.830845]  do_syscall_64+0x35/0x80
[  352.831445]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  352.832331] RIP: 0033:0x7f7bee973c17
[ 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47402</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipack: ipoctal: fix module reference leak

A reference to the carrier module was taken on every open but was only
released once when the final reference to the tty struct was dropped.

Fix this by taking the module reference and initialising the tty driver
data when installing the tty.</Note>
    </Notes>
    <CVE>CVE-2021-47403</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

HID: usbhid: free raw_report buffers in usbhid_stop

Free the unsent raw_report buffers when the device is removed.

Fixes a memory leak reported by syzbot at:
https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47</Note>
    </Notes>
    <CVE>CVE-2021-47405</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: add error checking to ext4_ext_replay_set_iblocks()

If the call to ext4_map_blocks() fails due to an corrupted file
system, ext4_ext_replay_set_iblocks() can get stuck in an infinite
loop.  This could be reproduced by running generic/526 with a file
system that has inline_data and fast_commit enabled.  The system will
repeatedly log to the console:

EXT4-fs warning (device dm-3): ext4_block_to_path:105: block 1074800922 &gt; max in inode 131076

and the stack that it gets stuck in is:

   ext4_block_to_path+0xe3/0x130
   ext4_ind_map_blocks+0x93/0x690
   ext4_map_blocks+0x100/0x660
   skip_hole+0x47/0x70
   ext4_ext_replay_set_iblocks+0x223/0x440
   ext4_fc_replay_inode+0x29e/0x3b0
   ext4_fc_replay+0x278/0x550
   do_one_pass+0x646/0xc10
   jbd2_journal_recover+0x14a/0x270
   jbd2_journal_load+0xc4/0x150
   ext4_load_journal+0x1f3/0x490
   ext4_fill_super+0x22d4/0x2c00

With this patch, generic/526 still fails, but system is no longer
locking up in a tight loop.  It's likely the root casue is that
fast_commit replay is corrupting file systems with inline_data, and we
probably need to add better error handling in the fast commit replay
code path beyond what is done here, which essentially just breaks the
infinite loop without reporting the to the higher levels of the code.</Note>
    </Notes>
    <CVE>CVE-2021-47406</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfilter: conntrack: serialize hash resizes and cleanups

Syzbot was able to trigger the following warning [1]

No repro found by syzbot yet but I was able to trigger similar issue
by having 2 scripts running in parallel, changing conntrack hash sizes,
and:

for j in `seq 1 1000` ; do unshare -n /bin/true &gt;/dev/null ; done

It would take more than 5 minutes for net_namespace structures
to be cleaned up.

This is because nf_ct_iterate_cleanup() has to restart everytime
a resize happened.

By adding a mutex, we can serialize hash resizes and cleanups
and also make get_next_corpse() faster by skipping over empty
buckets.

Even without resizes in the picture, this patch considerably
speeds up network namespace dismantles.

[1]
INFO: task syz-executor.0:8312 can't die for more than 144 seconds.
task:syz-executor.0  state:R  running task     stack:25672 pid: 8312 ppid:  6573 flags:0x00004006
Call Trace:
 context_switch kernel/sched/core.c:4955 [inline]
 __schedule+0x940/0x26f0 kernel/sched/core.c:6236
 preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:6408
 preempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:35
 __local_bh_enable_ip+0x109/0x120 kernel/softirq.c:390
 local_bh_enable include/linux/bottom_half.h:32 [inline]
 get_next_corpse net/netfilter/nf_conntrack_core.c:2252 [inline]
 nf_ct_iterate_cleanup+0x15a/0x450 net/netfilter/nf_conntrack_core.c:2275
 nf_conntrack_cleanup_net_list+0x14c/0x4f0 net/netfilter/nf_conntrack_core.c:2469
 ops_exit_list+0x10d/0x160 net/core/net_namespace.c:171
 setup_net+0x639/0xa30 net/core/net_namespace.c:349
 copy_net_ns+0x319/0x760 net/core/net_namespace.c:470
 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110
 unshare_nsproxy_namespaces+0xc1/0x1f0 kernel/nsproxy.c:226
 ksys_unshare+0x445/0x920 kernel/fork.c:3128
 __do_sys_unshare kernel/fork.c:3202 [inline]
 __se_sys_unshare kernel/fork.c:3200 [inline]
 __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3200
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f63da68e739
RSP: 002b:00007f63d7c05188 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
RAX: ffffffffffffffda RBX: 00007f63da792f80 RCX: 00007f63da68e739
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000000
RBP: 00007f63da6e8cc4 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f63da792f80
R13: 00007fff50b75d3f R14: 00007f63d7c05300 R15: 0000000000022000

Showing all locks held in the system:
1 lock held by khungtaskd/27:
 #0: ffffffff8b980020 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6446
2 locks held by kworker/u4:2/153:
 #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
 #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline]
 #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: atomic_long_set include/linux/atomic/atomic-instrumented.h:1198 [inline]
 #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:634 [inline]
 #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:661 [inline]
 #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x896/0x1690 kernel/workqueue.c:2268
 #1: ffffc9000140fdb0 ((kfence_timer).work){+.+.}-{0:0}, at: process_one_work+0x8ca/0x1690 kernel/workqueue.c:2272
1 lock held by systemd-udevd/2970:
1 lock held by in:imklog/6258:
 #0: ffff88807f970ff0 (&amp;f-&gt;f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:990
3 locks held by kworker/1:6/8158:
1 lock held by syz-executor.0/8312:
2 locks held by kworker/u4:13/9320:
1 lock held by
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47408</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: fix svm_migrate_fini warning

Device manager releases device-specific resources when a driver
disconnects from a device, devm_memunmap_pages and
devm_release_mem_region calls in svm_migrate_fini are redundant.

It causes below warning trace after patch "drm/amdgpu: Split
amdgpu_device_fini into early and late", so remove function
svm_migrate_fini.

BUG: https://gitlab.freedesktop.org/drm/amd/-/issues/1718

WARNING: CPU: 1 PID: 3646 at drivers/base/devres.c:795
devm_release_action+0x51/0x60
Call Trace:
    ? memunmap_pages+0x360/0x360
    svm_migrate_fini+0x2d/0x60 [amdgpu]
    kgd2kfd_device_exit+0x23/0xa0 [amdgpu]
    amdgpu_amdkfd_device_fini_sw+0x1d/0x30 [amdgpu]
    amdgpu_device_fini_sw+0x45/0x290 [amdgpu]
    amdgpu_driver_release_kms+0x12/0x30 [amdgpu]
    drm_dev_release+0x20/0x40 [drm]
    release_nodes+0x196/0x1e0
    device_release_driver_internal+0x104/0x1d0
    driver_detach+0x47/0x90
    bus_remove_driver+0x7a/0xd0
    pci_unregister_driver+0x3d/0x90
    amdgpu_exit+0x11/0x20 [amdgpu]</Note>
    </Notes>
    <CVE>CVE-2021-47410</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: don't call rq_qos_ops-&gt;done_bio if the bio isn't tracked

rq_qos framework is only applied on request based driver, so:

1) rq_qos_done_bio() needn't to be called for bio based driver

2) rq_qos_done_bio() needn't to be called for bio which isn't tracked,
such as bios ended from error handling code.

Especially in bio_endio():

1) request queue is referred via bio-&gt;bi_bdev-&gt;bd_disk-&gt;queue, which
may be gone since request queue refcount may not be held in above two
cases

2) q-&gt;rq_qos may be freed in blk_cleanup_queue() when calling into
__rq_qos_done_bio()

Fix the potential kernel panic by not calling rq_qos_ops-&gt;done_bio if
the bio isn't tracked. This way is safe because both ioc_rqos_done_bio()
and blkcg_iolatency_done_bio() are nop if the bio isn't tracked.</Note>
    </Notes>
    <CVE>CVE-2021-47412</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: chipidea: ci_hdrc_imx: Also search for 'phys' phandle

When passing 'phys' in the devicetree to describe the USB PHY phandle
(which is the recommended way according to
Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt) the
following NULL pointer dereference is observed on i.MX7 and i.MX8MM:

[    1.489344] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098
[    1.498170] Mem abort info:
[    1.500966]   ESR = 0x96000044
[    1.504030]   EC = 0x25: DABT (current EL), IL = 32 bits
[    1.509356]   SET = 0, FnV = 0
[    1.512416]   EA = 0, S1PTW = 0
[    1.515569]   FSC = 0x04: level 0 translation fault
[    1.520458] Data abort info:
[    1.523349]   ISV = 0, ISS = 0x00000044
[    1.527196]   CM = 0, WnR = 1
[    1.530176] [0000000000000098] user address but active_mm is swapper
[    1.536544] Internal error: Oops: 96000044 [#1] PREEMPT SMP
[    1.542125] Modules linked in:
[    1.545190] CPU: 3 PID: 7 Comm: kworker/u8:0 Not tainted 5.14.0-dirty #3
[    1.551901] Hardware name: Kontron i.MX8MM N801X S (DT)
[    1.557133] Workqueue: events_unbound deferred_probe_work_func
[    1.562984] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
[    1.568998] pc : imx7d_charger_detection+0x3f0/0x510
[    1.573973] lr : imx7d_charger_detection+0x22c/0x510

This happens because the charger functions check for the phy presence
inside the imx_usbmisc_data structure (data-&gt;usb_phy), but the chipidea
core populates the usb_phy passed via 'phys' inside 'struct ci_hdrc'
(ci-&gt;usb_phy) instead.

This causes the NULL pointer dereference inside imx7d_charger_detection().

Fix it by also searching for 'phys' in case 'fsl,usbphy' is not found.

Tested on a imx7s-warp board.</Note>
    </Notes>
    <CVE>CVE-2021-47413</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

riscv: Flush current cpu icache before other cpus

On SiFive Unmatched, I recently fell onto the following BUG when booting:

[    0.000000] ftrace: allocating 36610 entries in 144 pages
[    0.000000] Oops - illegal instruction [#1]
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.13.1+ #5
[    0.000000] Hardware name: SiFive HiFive Unmatched A00 (DT)
[    0.000000] epc : riscv_cpuid_to_hartid_mask+0x6/0xae
[    0.000000]  ra : __sbi_rfence_v02+0xc8/0x10a
[    0.000000] epc : ffffffff80007240 ra : ffffffff80009964 sp : ffffffff81803e10
[    0.000000]  gp : ffffffff81a1ea70 tp : ffffffff8180f500 t0 : ffffffe07fe30000
[    0.000000]  t1 : 0000000000000004 t2 : 0000000000000000 s0 : ffffffff81803e60
[    0.000000]  s1 : 0000000000000000 a0 : ffffffff81a22238 a1 : ffffffff81803e10
[    0.000000]  a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000
[    0.000000]  a5 : 0000000000000000 a6 : ffffffff8000989c a7 : 0000000052464e43
[    0.000000]  s2 : ffffffff81a220c8 s3 : 0000000000000000 s4 : 0000000000000000
[    0.000000]  s5 : 0000000000000000 s6 : 0000000200000100 s7 : 0000000000000001
[    0.000000]  s8 : ffffffe07fe04040 s9 : ffffffff81a22c80 s10: 0000000000001000
[    0.000000]  s11: 0000000000000004 t3 : 0000000000000001 t4 : 0000000000000008
[    0.000000]  t5 : ffffffcf04000808 t6 : ffffffe3ffddf188
[    0.000000] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000002
[    0.000000] [&lt;ffffffff80007240&gt;] riscv_cpuid_to_hartid_mask+0x6/0xae
[    0.000000] [&lt;ffffffff80009474&gt;] sbi_remote_fence_i+0x1e/0x26
[    0.000000] [&lt;ffffffff8000b8f4&gt;] flush_icache_all+0x12/0x1a
[    0.000000] [&lt;ffffffff8000666c&gt;] patch_text_nosync+0x26/0x32
[    0.000000] [&lt;ffffffff8000884e&gt;] ftrace_init_nop+0x52/0x8c
[    0.000000] [&lt;ffffffff800f051e&gt;] ftrace_process_locs.isra.0+0x29c/0x360
[    0.000000] [&lt;ffffffff80a0e3c6&gt;] ftrace_init+0x80/0x130
[    0.000000] [&lt;ffffffff80a00f8c&gt;] start_kernel+0x5c4/0x8f6
[    0.000000] ---[ end trace f67eb9af4d8d492b ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

While ftrace is looping over a list of addresses to patch, it always failed
when patching the same function: riscv_cpuid_to_hartid_mask. Looking at the
backtrace, the illegal instruction is encountered in this same function.
However, patch_text_nosync, after patching the instructions, calls
flush_icache_range. But looking at what happens in this function:

flush_icache_range -&gt; flush_icache_all
                   -&gt; sbi_remote_fence_i
                   -&gt; __sbi_rfence_v02
                   -&gt; riscv_cpuid_to_hartid_mask

The icache and dcache of the current cpu are never synchronized between the
patching of riscv_cpuid_to_hartid_mask and calling this same function.

So fix this by flushing the current cpu's icache before asking for the other
cpus to do the same.</Note>
    </Notes>
    <CVE>CVE-2021-47414</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iwlwifi: mvm: Fix possible NULL dereference

In __iwl_mvm_remove_time_event() check that 'te_data-&gt;vif' is NULL
before dereferencing it.</Note>
    </Notes>
    <CVE>CVE-2021-47415</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

libbpf: Fix memory leak in strset

Free struct strset itself, not just its internal parts.</Note>
    </Notes>
    <CVE>CVE-2021-47417</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/sched: sch_taprio: properly cancel timer from taprio_destroy()

There is a comment in qdisc_create() about us not calling ops-&gt;reset()
in some cases.

err_out4:
	/*
	 * Any broken qdiscs that would require a ops-&gt;reset() here?
	 * The qdisc was never in action so it shouldn't be necessary.
	 */

As taprio sets a timer before actually receiving a packet, we need
to cancel it from ops-&gt;destroy, just in case ops-&gt;reset has not
been called.

syzbot reported:

ODEBUG: free active (active state 0) object type: hrtimer hint: advance_sched+0x0/0x9a0 arch/x86/include/asm/atomic64_64.h:22
WARNING: CPU: 0 PID: 8441 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505
Modules linked in:
CPU: 0 PID: 8441 Comm: syz-executor813 Not tainted 5.14.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505
Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd e0 d3 e3 89 4c 89 ee 48 c7 c7 e0 c7 e3 89 e8 5b 86 11 05 &lt;0f&gt; 0b 83 05 85 03 92 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3
RSP: 0018:ffffc9000130f330 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
RDX: ffff88802baeb880 RSI: ffffffff815d87b5 RDI: fffff52000261e58
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815d25ee R11: 0000000000000000 R12: ffffffff898dd020
R13: ffffffff89e3ce20 R14: ffffffff81653630 R15: dffffc0000000000
FS:  0000000000f0d300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffb64b3e000 CR3: 0000000036557000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 __debug_check_no_obj_freed lib/debugobjects.c:987 [inline]
 debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1018
 slab_free_hook mm/slub.c:1603 [inline]
 slab_free_freelist_hook+0x171/0x240 mm/slub.c:1653
 slab_free mm/slub.c:3213 [inline]
 kfree+0xe4/0x540 mm/slub.c:4267
 qdisc_create+0xbcf/0x1320 net/sched/sch_api.c:1299
 tc_modify_qdisc+0x4c8/0x1a60 net/sched/sch_api.c:1663
 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571
 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:2403
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2457
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2486
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80</Note>
    </Notes>
    <CVE>CVE-2021-47419</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: fix a potential ttm-&gt;sg memory leak

Memory is allocated for ttm-&gt;sg by kmalloc in kfd_mem_dmamap_userptr,
but isn't freed by kfree in kfd_mem_dmaunmap_userptr. Free it!</Note>
    </Notes>
    <CVE>CVE-2021-47420</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume

In current code, when a PCI error state pci_channel_io_normal is detectd,
it will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI
driver will continue the execution of PCI resume callback report_resume by
pci_walk_bridge, and the callback will go into amdgpu_pci_resume
finally, where write lock is releasd unconditionally without acquiring
such lock first. In this case, a deadlock will happen when other threads
start to acquire the read lock.

To fix this, add a member in amdgpu_device strucutre to cache
pci_channel_state, and only continue the execution in amdgpu_pci_resume
when it's pci_channel_io_frozen.</Note>
    </Notes>
    <CVE>CVE-2021-47421</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/kms/nv50-: 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-47422</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i40e: Fix 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i2c: acpi: fix resource leak in reconfiguration device addition

acpi_i2c_find_adapter_by_handle() calls bus_find_device() which takes a
reference on the adapter which is never released which will result in a
reference count leak and render the adapter unremovable.  Make sure to
put the adapter after creating the client in the same manner that we do
for OF.

[wsa: fixed title]</Note>
    </Notes>
    <CVE>CVE-2021-47425</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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, s390: Fix potential memory leak about jit_data

Make sure to free jit_data through kfree() in the error path.</Note>
    </Notes>
    <CVE>CVE-2021-47426</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: iscsi: Fix iscsi_task use after free

Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn")
added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but
then also changed the handling of the case where we detect an already
completed task where we now end up doing a goto to the common put/cleanup
code. This results in a iscsi_task use after free, because the common
cleanup code will do a put on the iscsi_task.

This reverts the goto and moves the iscsi_get_conn() to after we've checked
if the iscsi_task is valid.</Note>
    </Notes>
    <CVE>CVE-2021-47427</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 program check interrupt emergency stack path

Emergency stack path was jumping into a 3: label inside the
__GEN_COMMON_BODY macro for the normal path after it had finished,
rather than jumping over it. By a small miracle this is the correct
place to build up a new interrupt frame with the existing stack
pointer, so things basically worked okay with an added weird looking
700 trap frame on top (which had the wrong -&gt;nip so it didn't decode
bug messages either).

Fix this by avoiding using numeric labels when jumping over non-trivial
macros.

Before:

 LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
 Modules linked in:
 CPU: 0 PID: 88 Comm: sh Not tainted 5.15.0-rc2-00034-ge057cdade6e5 #2637
 NIP:  7265677368657265 LR: c00000000006c0c8 CTR: c0000000000097f0
 REGS: c0000000fffb3a50 TRAP: 0700   Not tainted
 MSR:  9000000000021031 &lt;SF,HV,ME,IR,DR,LE&gt;  CR: 00000700  XER: 20040000
 CFAR: c0000000000098b0 IRQMASK: 0
 GPR00: c00000000006c964 c0000000fffb3cf0 c000000001513800 0000000000000000
 GPR04: 0000000048ab0778 0000000042000000 0000000000000000 0000000000001299
 GPR08: 000001e447c718ec 0000000022424282 0000000000002710 c00000000006bee8
 GPR12: 9000000000009033 c0000000016b0000 00000000000000b0 0000000000000001
 GPR16: 0000000000000000 0000000000000002 0000000000000000 0000000000000ff8
 GPR20: 0000000000001fff 0000000000000007 0000000000000080 00007fff89d90158
 GPR24: 0000000002000000 0000000002000000 0000000000000255 0000000000000300
 GPR28: c000000001270000 0000000042000000 0000000048ab0778 c000000080647e80
 NIP [7265677368657265] 0x7265677368657265
 LR [c00000000006c0c8] ___do_page_fault+0x3f8/0xb10
 Call Trace:
 [c0000000fffb3cf0] [c00000000000bdac] soft_nmi_common+0x13c/0x1d0 (unreliable)
 --- interrupt: 700 at decrementer_common_virt+0xb8/0x230
 NIP:  c0000000000098b8 LR: c00000000006c0c8 CTR: c0000000000097f0
 REGS: c0000000fffb3d60 TRAP: 0700   Not tainted
 MSR:  9000000000021031 &lt;SF,HV,ME,IR,DR,LE&gt;  CR: 22424282  XER: 20040000
 CFAR: c0000000000098b0 IRQMASK: 0
 GPR00: c00000000006c964 0000000000002400 c000000001513800 0000000000000000
 GPR04: 0000000048ab0778 0000000042000000 0000000000000000 0000000000001299
 GPR08: 000001e447c718ec 0000000022424282 0000000000002710 c00000000006bee8
 GPR12: 9000000000009033 c0000000016b0000 00000000000000b0 0000000000000001
 GPR16: 0000000000000000 0000000000000002 0000000000000000 0000000000000ff8
 GPR20: 0000000000001fff 0000000000000007 0000000000000080 00007fff89d90158
 GPR24: 0000000002000000 0000000002000000 0000000000000255 0000000000000300
 GPR28: c000000001270000 0000000042000000 0000000048ab0778 c000000080647e80
 NIP [c0000000000098b8] decrementer_common_virt+0xb8/0x230
 LR [c00000000006c0c8] ___do_page_fault+0x3f8/0xb10
 --- interrupt: 700
 Instruction dump:
 XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
 XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
 ---[ end trace 6d28218e0cc3c949 ]---

After:

 ------------[ cut here ]------------
 kernel BUG at arch/powerpc/kernel/exceptions-64s.S:491!
 Oops: Exception in kernel mode, sig: 5 [#1]
 LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
 Modules linked in:
 CPU: 0 PID: 88 Comm: login Not tainted 5.15.0-rc2-00034-ge057cdade6e5-dirty #2638
 NIP:  c0000000000098b8 LR: c00000000006bf04 CTR: c0000000000097f0
 REGS: c0000000fffb3d60 TRAP: 0700   Not tainted
 MSR:  9000000000021031 &lt;SF,HV,ME,IR,DR,LE&gt;  CR: 24482227  XER: 00040000
 CFAR: c0000000000098b0 IRQMASK: 0
 GPR00: c00000000006bf04 0000000000002400 c000000001513800 c000000001271868
 GPR04: 00000000100f0d29 0000000042000000 0000000000000007 0000000000000009
 GPR08: 00000000100f0d29 0000000024482227 0000000000002710 c000000000181b3c
 GPR12: 9000000000009033 c0000000016b0000 00000000100f0d29 c000000005b22f00
 GPR16: 00000000ffff0000 0000000000000001 0000000000000009 00000000100eed90
 GPR20: 00000000100eed90 00000
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47428</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 unrecoverable MCE calling async handler from NMI

The machine check handler is not considered NMI on 64s. The early
handler is the true NMI handler, and then it schedules the
machine_check_exception handler to run when interrupts are enabled.

This works fine except the case of an unrecoverable MCE, where the true
NMI is taken when MSR[RI] is clear, it can not recover, so it calls
machine_check_exception directly so something might be done about it.

Calling an async handler from NMI context can result in irq state and
other things getting corrupted. This can also trigger the BUG at
  arch/powerpc/include/asm/interrupt.h:168
  BUG_ON(!arch_irq_disabled_regs(regs) &amp;&amp; !(regs-&gt;msr &amp; MSR_EE));

Fix this by making an _async version of the handler which is called
in the normal case, and a NMI version that is called for unrecoverable
interrupts.</Note>
    </Notes>
    <CVE>CVE-2021-47429</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/entry: Clear X86_FEATURE_SMAP when CONFIG_X86_SMAP=n

Commit

  3c73b81a9164 ("x86/entry, selftests: Further improve user entry sanity checks")

added a warning if AC is set when in the kernel.

Commit

  662a0221893a3d ("x86/entry: Fix AC assertion")

changed the warning to only fire if the CPU supports SMAP.

However, the warning can still trigger on a machine that supports SMAP
but where it's disabled in the kernel config and when running the
syscall_nt selftest, for example:

  ------------[ cut here ]------------
  WARNING: CPU: 0 PID: 49 at irqentry_enter_from_user_mode
  CPU: 0 PID: 49 Comm: init Tainted: G                T 5.15.0-rc4+ #98 e6202628ee053b4f310759978284bd8bb0ce6905
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
  RIP: 0010:irqentry_enter_from_user_mode
  ...
  Call Trace:
   ? irqentry_enter
   ? exc_general_protection
   ? asm_exc_general_protection
   ? asm_exc_general_protectio

IS_ENABLED(CONFIG_X86_SMAP) could be added to the warning condition, but
even this would not be enough in case SMAP is disabled at boot time with
the "nosmap" parameter.

To be consistent with "nosmap" behaviour, clear X86_FEATURE_SMAP when
!CONFIG_X86_SMAP.

Found using entry-fuzz + satrandconfig.

 [ bp: Massage commit message. ]</Note>
    </Notes>
    <CVE>CVE-2021-47430</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix abort logic in btrfs_replace_file_extents

Error injection testing uncovered a case where we'd end up with a
corrupt file system with a missing extent in the middle of a file.  This
occurs because the if statement to decide if we should abort is wrong.

The only way we would abort in this case is if we got a ret !=
-EOPNOTSUPP and we called from the file clone code.  However the
prealloc code uses this path too.  Instead we need to abort if there is
an error, and the only error we _don't_ abort on is -EOPNOTSUPP and only
if we came from the clone file code.</Note>
    </Notes>
    <CVE>CVE-2021-47433</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: adis16475: fix deadlock on frequency set

With commit 39c024b51b560
("iio: adis16475: improve sync scale mode handling"), two deadlocks were
introduced:
 1) The call to 'adis_write_reg_16()' was not changed to it's unlocked
    version.
 2) The lock was not being released on the success path of the function.

This change fixes both these issues.</Note>
    </Notes>
    <CVE>CVE-2021-47437</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: dsa: microchip: Added the condition for scheduling ksz_mib_read_work

When the ksz module is installed and removed using rmmod, kernel crashes
with null pointer dereferrence error. During rmmod, ksz_switch_remove
function tries to cancel the mib_read_workqueue using
cancel_delayed_work_sync routine and unregister switch from dsa.

During dsa_unregister_switch it calls ksz_mac_link_down, which in turn
reschedules the workqueue since mib_interval is non-zero.
Due to which queue executed after mib_interval and it tries to access
dp-&gt;slave. But the slave is unregistered in the ksz_switch_remove
function. Hence kernel crashes.

To avoid this crash, before canceling the workqueue, resetted the
mib_interval to 0.

v1 -&gt; v2:
-Removed the if condition in ksz_mib_read_work</Note>
    </Notes>
    <CVE>CVE-2021-47439</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: encx24j600: check error in devm_regmap_init_encx24j600

devm_regmap_init may return error which caused by like out of memory,
this will results in null pointer dereference later when reading
or writing register:

general protection fault in encx24j600_spi_probe
KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]
CPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540
Code: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00
RSP: 0018:ffffc900010476b8 EFLAGS: 00010207
RAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 0000000000000000
RDX: 0000000000000012 RSI: ffff888002de0000 RDI: 0000000000000094
RBP: ffff888013c9a000 R08: 0000000000000000 R09: fffffbfff3f9cc6a
R10: ffffc900010476e8 R11: fffffbfff3f9cc69 R12: 0000000000000001
R13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08
FS:  00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459
 spi_probe drivers/spi/spi.c:397
 really_probe drivers/base/dd.c:517
 __driver_probe_device drivers/base/dd.c:751
 driver_probe_device drivers/base/dd.c:782
 __device_attach_driver drivers/base/dd.c:899
 bus_for_each_drv drivers/base/bus.c:427
 __device_attach drivers/base/dd.c:971
 bus_probe_device drivers/base/bus.c:487
 device_add drivers/base/core.c:3364
 __spi_add_device drivers/spi/spi.c:599
 spi_add_device drivers/spi/spi.c:641
 spi_new_device drivers/spi/spi.c:717
 new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d00630982840568e85e]
 dev_attr_store drivers/base/core.c:2074
 sysfs_kf_write fs/sysfs/file.c:139
 kernfs_fop_write_iter fs/kernfs/file.c:300
 new_sync_write fs/read_write.c:508 (discriminator 4)
 vfs_write fs/read_write.c:594
 ksys_write fs/read_write.c:648
 do_syscall_64 arch/x86/entry/common.c:50
 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113

Add error check in devm_regmap_init_encx24j600 to avoid this situation.</Note>
    </Notes>
    <CVE>CVE-2021-47440</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mlxsw: thermal: Fix out-of-bounds memory accesses

Currently, mlxsw allows cooling states to be set above the maximum
cooling state supported by the driver:

 # cat /sys/class/thermal/thermal_zone2/cdev0/type
 mlxsw_fan
 # cat /sys/class/thermal/thermal_zone2/cdev0/max_state
 10
 # echo 18 &gt; /sys/class/thermal/thermal_zone2/cdev0/cur_state
 # echo $?
 0

This results in out-of-bounds memory accesses when thermal state
transition statistics are enabled (CONFIG_THERMAL_STATISTICS=y), as the
transition table is accessed with a too large index (state) [1].

According to the thermal maintainer, it is the responsibility of the
driver to reject such operations [2].

Therefore, return an error when the state to be set exceeds the maximum
cooling state supported by the driver.

To avoid dead code, as suggested by the thermal maintainer [3],
partially revert commit a421ce088ac8 ("mlxsw: core: Extend cooling
device with cooling levels") that tried to interpret these invalid
cooling states (above the maximum) in a special way. The cooling levels
array is not removed in order to prevent the fans going below 20% PWM,
which would cause them to get stuck at 0% PWM.

[1]
BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x271/0x290
Read of size 4 at addr ffff8881052f7bf8 by task kworker/0:0/5

CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.15.0-rc3-custom-45935-gce1adf704b14 #122
Hardware name: Mellanox Technologies Ltd. "MSN2410-CB2FO"/"SA000874", BIOS 4.6.5 03/08/2016
Workqueue: events_freezable_power_ thermal_zone_device_check
Call Trace:
 dump_stack_lvl+0x8b/0xb3
 print_address_description.constprop.0+0x1f/0x140
 kasan_report.cold+0x7f/0x11b
 thermal_cooling_device_stats_update+0x271/0x290
 __thermal_cdev_update+0x15e/0x4e0
 thermal_cdev_update+0x9f/0xe0
 step_wise_throttle+0x770/0xee0
 thermal_zone_device_update+0x3f6/0xdf0
 process_one_work+0xa42/0x1770
 worker_thread+0x62f/0x13e0
 kthread+0x3ee/0x4e0
 ret_from_fork+0x1f/0x30

Allocated by task 1:
 kasan_save_stack+0x1b/0x40
 __kasan_kmalloc+0x7c/0x90
 thermal_cooling_device_setup_sysfs+0x153/0x2c0
 __thermal_cooling_device_register.part.0+0x25b/0x9c0
 thermal_cooling_device_register+0xb3/0x100
 mlxsw_thermal_init+0x5c5/0x7e0
 __mlxsw_core_bus_device_register+0xcb3/0x19c0
 mlxsw_core_bus_device_register+0x56/0xb0
 mlxsw_pci_probe+0x54f/0x710
 local_pci_probe+0xc6/0x170
 pci_device_probe+0x2b2/0x4d0
 really_probe+0x293/0xd10
 __driver_probe_device+0x2af/0x440
 driver_probe_device+0x51/0x1e0
 __driver_attach+0x21b/0x530
 bus_for_each_dev+0x14c/0x1d0
 bus_add_driver+0x3ac/0x650
 driver_register+0x241/0x3d0
 mlxsw_sp_module_init+0xa2/0x174
 do_one_initcall+0xee/0x5f0
 kernel_init_freeable+0x45a/0x4de
 kernel_init+0x1f/0x210
 ret_from_fork+0x1f/0x30

The buggy address belongs to the object at ffff8881052f7800
 which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 1016 bytes inside of
 1024-byte region [ffff8881052f7800, ffff8881052f7c00)
The buggy address belongs to the page:
page:0000000052355272 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1052f0
head:0000000052355272 order:3 compound_mapcount:0 compound_pincount:0
flags: 0x200000000010200(slab|head|node=0|zone=2)
raw: 0200000000010200 ffffea0005034800 0000000300000003 ffff888100041dc0
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff8881052f7a80: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc
 ffff8881052f7b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
&gt;ffff8881052f7b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                                ^
 ffff8881052f7c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff8881052f7c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

[2] https://lore.kernel.org/linux-pm/9aca37cb-1629-5c67-
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47441</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: digital: fix possible memory leak in digital_in_send_sdd_req()

'skb' is allocated in digital_in_send_sdd_req(), but not free when
digital_in_send_cmd() failed, which will cause memory leak. Fix it
by freeing 'skb' if digital_in_send_cmd() return failed.</Note>
    </Notes>
    <CVE>CVE-2021-47442</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: digital: fix possible memory leak in digital_tg_listen_mdaa()

'params' is allocated in digital_tg_listen_mdaa(), but not free when
digital_send_cmd() failed, which will cause memory leak. Fix it by
freeing 'params' if digital_send_cmd() return failed.</Note>
    </Notes>
    <CVE>CVE-2021-47443</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/edid: In connector_bad_edid() cap num_of_ext by num_blocks read

In commit e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid
corruption test") the function connector_bad_edid() started assuming
that the memory for the EDID passed to it was big enough to hold
`edid[0x7e] + 1` blocks of data (1 extra for the base block). It
completely ignored the fact that the function was passed `num_blocks`
which indicated how much memory had been allocated for the EDID.

Let's fix this by adding a bounds check.

This is important for handling the case where there's an error in the
first block of the EDID. In that case we will call
connector_bad_edid() without having re-allocated memory based on
`edid[0x7e]`.</Note>
    </Notes>
    <CVE>CVE-2021-47444</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/a4xx: fix error handling in a4xx_gpu_init()

This code returns 1 on error instead of a negative error.  It leads to
an Oops in the caller.  A second problem is that the check for
"if (ret != -ENODATA)" cannot be true because "ret" is set to 1.</Note>
    </Notes>
    <CVE>CVE-2021-47446</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/a3xx: fix error handling in a3xx_gpu_init()

These error paths returned 1 on failure, instead of a negative error
code.  This would lead to an Oops in the caller.  A second problem is
that the check for "if (ret != -ENODATA)" did not work because "ret" was
set to 1.</Note>
    </Notes>
    <CVE>CVE-2021-47447</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mptcp: fix possible stall on recvmsg()

recvmsg() can enter an infinite loop if the caller provides the
MSG_WAITALL, the data present in the receive queue is not sufficient to
fulfill the request, and no more data is received by the peer.

When the above happens, mptcp_wait_data() will always return with
no wait, as the MPTCP_DATA_READY flag checked by such function is
set and never cleared in such code path.

Leveraging the above syzbot was able to trigger an RCU stall:

rcu: INFO: rcu_preempt self-detected stall on CPU
rcu:    0-...!: (10499 ticks this GP) idle=0af/1/0x4000000000000000 softirq=10678/10678 fqs=1
        (t=10500 jiffies g=13089 q=109)
rcu: rcu_preempt kthread starved for 10497 jiffies! g13089 f0x0 RCU_GP_WAIT_FQS(5) -&gt;state=0x0 -&gt;cpu=1
rcu:    Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt     state:R  running task     stack:28696 pid:   14 ppid:     2 flags:0x00004000
Call Trace:
 context_switch kernel/sched/core.c:4955 [inline]
 __schedule+0x940/0x26f0 kernel/sched/core.c:6236
 schedule+0xd3/0x270 kernel/sched/core.c:6315
 schedule_timeout+0x14a/0x2a0 kernel/time/timer.c:1881
 rcu_gp_fqs_loop+0x186/0x810 kernel/rcu/tree.c:1955
 rcu_gp_kthread+0x1de/0x320 kernel/rcu/tree.c:2128
 kthread+0x405/0x4f0 kernel/kthread.c:327
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
rcu: Stack dump where RCU GP kthread last ran:
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 8510 Comm: syz-executor827 Not tainted 5.15.0-rc2-next-20210920-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:84 [inline]
RIP: 0010:memory_is_nonzero mm/kasan/generic.c:102 [inline]
RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:128 [inline]
RIP: 0010:memory_is_poisoned mm/kasan/generic.c:159 [inline]
RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline]
RIP: 0010:kasan_check_range+0xc8/0x180 mm/kasan/generic.c:189
Code: 38 00 74 ed 48 8d 50 08 eb 09 48 83 c0 01 48 39 d0 74 7a 80 38 00 74 f2 48 89 c2 b8 01 00 00 00 48 85 d2 75 56 5b 5d 41 5c c3 &lt;48&gt; 85 d2 74 5e 48 01 ea eb 09 48 83 c0 01 48 39 d0 74 50 80 38 00
RSP: 0018:ffffc9000cd676c8 EFLAGS: 00000283
RAX: ffffed100e9a110e RBX: ffffed100e9a110f RCX: ffffffff88ea062a
RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888074d08870
RBP: ffffed100e9a110e R08: 0000000000000001 R09: ffff888074d08877
R10: ffffed100e9a110e R11: 0000000000000000 R12: ffff888074d08000
R13: ffff888074d08000 R14: ffff888074d08088 R15: ffff888074d08000
FS:  0000555556d8e300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
S:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000180 CR3: 0000000068909000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 instrument_atomic_read_write include/linux/instrumented.h:101 [inline]
 test_and_clear_bit include/asm-generic/bitops/instrumented-atomic.h:83 [inline]
 mptcp_release_cb+0x14a/0x210 net/mptcp/protocol.c:3016
 release_sock+0xb4/0x1b0 net/core/sock.c:3204
 mptcp_wait_data net/mptcp/protocol.c:1770 [inline]
 mptcp_recvmsg+0xfd1/0x27b0 net/mptcp/protocol.c:2080
 inet6_recvmsg+0x11b/0x5e0 net/ipv6/af_inet6.c:659
 sock_recvmsg_nosec net/socket.c:944 [inline]
 ____sys_recvmsg+0x527/0x600 net/socket.c:2626
 ___sys_recvmsg+0x127/0x200 net/socket.c:2670
 do_recvmmsg+0x24d/0x6d0 net/socket.c:2764
 __sys_recvmmsg net/socket.c:2843 [inline]
 __do_sys_recvmmsg net/socket.c:2866 [inline]
 __se_sys_recvmmsg net/socket.c:2859 [inline]
 __x64_sys_recvmmsg+0x20b/0x260 net/socket.c:2859
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fc200d2
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47448</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: fix locking for Tx timestamp tracking flush

Commit 4dd0d5c33c3e ("ice: add lock around Tx timestamp tracker flush")
added a lock around the Tx timestamp tracker flow which is used to
cleanup any left over SKBs and prepare for device removal.

This lock is problematic because it is being held around a call to
ice_clear_phy_tstamp. The clear function takes a mutex to send a PHY
write command to firmware. This could lead to a deadlock if the mutex
actually sleeps, and causes the following warning on a kernel with
preemption debugging enabled:

[  715.419426] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:573
[  715.427900] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 3100, name: rmmod
[  715.435652] INFO: lockdep is turned off.
[  715.439591] Preemption disabled at:
[  715.439594] [&lt;0000000000000000&gt;] 0x0
[  715.446678] CPU: 52 PID: 3100 Comm: rmmod Tainted: G        W  OE     5.15.0-rc4+ #42 bdd7ec3018e725f159ca0d372ce8c2c0e784891c
[  715.458058] Hardware name: Intel Corporation S2600STQ/S2600STQ, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020
[  715.468483] Call Trace:
[  715.470940]  dump_stack_lvl+0x6a/0x9a
[  715.474613]  ___might_sleep.cold+0x224/0x26a
[  715.478895]  __mutex_lock+0xb3/0x1440
[  715.482569]  ? stack_depot_save+0x378/0x500
[  715.486763]  ? ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[  715.494979]  ? kfree+0xc1/0x520
[  715.498128]  ? mutex_lock_io_nested+0x12a0/0x12a0
[  715.502837]  ? kasan_set_free_info+0x20/0x30
[  715.507110]  ? __kasan_slab_free+0x10b/0x140
[  715.511385]  ? slab_free_freelist_hook+0xc7/0x220
[  715.516092]  ? kfree+0xc1/0x520
[  715.519235]  ? ice_deinit_lag+0x16c/0x220 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[  715.527359]  ? ice_remove+0x1cf/0x6a0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[  715.535133]  ? pci_device_remove+0xab/0x1d0
[  715.539318]  ? __device_release_driver+0x35b/0x690
[  715.544110]  ? driver_detach+0x214/0x2f0
[  715.548035]  ? bus_remove_driver+0x11d/0x2f0
[  715.552309]  ? pci_unregister_driver+0x26/0x250
[  715.556840]  ? ice_module_exit+0xc/0x2f [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[  715.564799]  ? __do_sys_delete_module.constprop.0+0x2d8/0x4e0
[  715.570554]  ? do_syscall_64+0x3b/0x90
[  715.574303]  ? entry_SYSCALL_64_after_hwframe+0x44/0xae
[  715.579529]  ? start_flush_work+0x542/0x8f0
[  715.583719]  ? ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[  715.591923]  ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[  715.599960]  ? wait_for_completion_io+0x250/0x250
[  715.604662]  ? lock_acquire+0x196/0x200
[  715.608504]  ? do_raw_spin_trylock+0xa5/0x160
[  715.612864]  ice_sbq_rw_reg+0x1e6/0x2f0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[  715.620813]  ? ice_reset+0x130/0x130 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[  715.628497]  ? __debug_check_no_obj_freed+0x1e8/0x3c0
[  715.633550]  ? trace_hardirqs_on+0x1c/0x130
[  715.637748]  ice_write_phy_reg_e810+0x70/0xf0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[  715.646220]  ? do_raw_spin_trylock+0xa5/0x160
[  715.650581]  ? ice_ptp_release+0x910/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[  715.658797]  ? ice_ptp_release+0x255/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[  715.667013]  ice_clear_phy_tstamp+0x2c/0x110 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[  715.675403]  ice_ptp_release+0x408/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[  715.683440]  ice_remove+0x560/0x6a0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]
[  715.691037]  ? _raw_spin_unlock_irqrestore+0x46/0x73
[  715.696005]  pci_device_remove+0xab/0x1d0
[  715.700018]  __device_release_driver+0x35b/0x690
[  715.704637]  driver_detach+0x214/0x2f0
[  715.708389]  bus_remove_driver+0x11d/0x2f0
[  715.712489]  pci_unregister_driver+0x26/0x250
[  71
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47449</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Fix host stage-2 PGD refcount

The KVM page-table library refcounts the pages of concatenated stage-2
PGDs individually. However, when running KVM in protected mode, the
host's stage-2 PGD is currently managed by EL2 as a single high-order
compound page, which can cause the refcount of the tail pages to reach 0
when they shouldn't, hence corrupting the page-table.

Fix this by introducing a new hyp_split_page() helper in the EL2 page
allocator (matching the kernel's split_page() function), and make use of
it from host_s2_zalloc_pages_exact().</Note>
    </Notes>
    <CVE>CVE-2021-47450</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: xt_IDLETIMER: fix panic that occurs when timer_type has garbage value

Currently, when the rule related to IDLETIMER is added, idletimer_tg timer
structure is initialized by kmalloc on executing idletimer_tg_create
function. However, in this process timer-&gt;timer_type is not defined to
a specific value. Thus, timer-&gt;timer_type has garbage value and it occurs
kernel panic. So, this commit fixes the panic by initializing
timer-&gt;timer_type using kzalloc instead of kmalloc.

Test commands:
    # iptables -A OUTPUT -j IDLETIMER --timeout 1 --label test
    $ cat /sys/class/xt_idletimer/timers/test
      Killed

Splat looks like:
    BUG: KASAN: user-memory-access in alarm_expires_remaining+0x49/0x70
    Read of size 8 at addr 0000002e8c7bc4c8 by task cat/917
    CPU: 12 PID: 917 Comm: cat Not tainted 5.14.0+ #3 79940a339f71eb14fc81aee1757a20d5bf13eb0e
    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
    Call Trace:
     dump_stack_lvl+0x6e/0x9c
     kasan_report.cold+0x112/0x117
     ? alarm_expires_remaining+0x49/0x70
     __asan_load8+0x86/0xb0
     alarm_expires_remaining+0x49/0x70
     idletimer_tg_show+0xe5/0x19b [xt_IDLETIMER 11219304af9316a21bee5ba9d58f76a6b9bccc6d]
     dev_attr_show+0x3c/0x60
     sysfs_kf_seq_show+0x11d/0x1f0
     ? device_remove_bin_file+0x20/0x20
     kernfs_seq_show+0xa4/0xb0
     seq_read_iter+0x29c/0x750
     kernfs_fop_read_iter+0x25a/0x2c0
     ? __fsnotify_parent+0x3d1/0x570
     ? iov_iter_init+0x70/0x90
     new_sync_read+0x2a7/0x3d0
     ? __x64_sys_llseek+0x230/0x230
     ? rw_verify_area+0x81/0x150
     vfs_read+0x17b/0x240
     ksys_read+0xd9/0x180
     ? vfs_write+0x460/0x460
     ? do_syscall_64+0x16/0xc0
     ? lockdep_hardirqs_on+0x79/0x120
     __x64_sys_read+0x43/0x50
     do_syscall_64+0x3b/0xc0
     entry_SYSCALL_64_after_hwframe+0x44/0xae
    RIP: 0033:0x7f0cdc819142
    Code: c0 e9 c2 fe ff ff 50 48 8d 3d 3a ca 0a 00 e8 f5 19 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 ec 28 48 89 54 24
    RSP: 002b:00007fff28eee5b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
    RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f0cdc819142
    RDX: 0000000000020000 RSI: 00007f0cdc032000 RDI: 0000000000000003
    RBP: 00007f0cdc032000 R08: 00007f0cdc031010 R09: 0000000000000000
    R10: 0000000000000022 R11: 0000000000000246 R12: 00005607e9ee31f0
    R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000</Note>
    </Notes>
    <CVE>CVE-2021-47451</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: skip netdev events generated on netns removal

syzbot reported following (harmless) WARN:

 WARNING: CPU: 1 PID: 2648 at net/netfilter/core.c:468
  nft_netdev_unregister_hooks net/netfilter/nf_tables_api.c:230 [inline]
  nf_tables_unregister_hook include/net/netfilter/nf_tables.h:1090 [inline]
  __nft_release_basechain+0x138/0x640 net/netfilter/nf_tables_api.c:9524
  nft_netdev_event net/netfilter/nft_chain_filter.c:351 [inline]
  nf_tables_netdev_event+0x521/0x8a0 net/netfilter/nft_chain_filter.c:382

reproducer:
unshare -n bash -c 'ip link add br0 type bridge; nft add table netdev t ; \
 nft add chain netdev t ingress \{ type filter hook ingress device "br0" \
 priority 0\; policy drop\; \}'

Problem is that when netns device exit hooks create the UNREGISTER
event, the .pre_exit hook for nf_tables core has already removed the
base hook.  Notifier attempts to do this again.

The need to do base hook unregister unconditionally was needed in the past,
because notifier was last stage where reg-&gt;dev dereference was safe.

Now that nf_tables does the hook removal in .pre_exit, this isn't
needed anymore.</Note>
    </Notes>
    <CVE>CVE-2021-47452</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: Avoid crash from unnecessary IDA free

In the remove path, there is an attempt to free the aux_idx IDA whether
it was allocated or not.  This can potentially cause a crash when
unloading the driver on systems that do not initialize support for RDMA.
But, this free cannot be gated by the status bit for RDMA, since it is
allocated if the driver detects support for RDMA at probe time, but the
driver can enter into a state where RDMA is not supported after the IDA
has been allocated at probe time and this would lead to a memory leak.

Initialize aux_idx to an invalid value and check for a valid value when
unloading to determine if an IDA free is necessary.</Note>
    </Notes>
    <CVE>CVE-2021-47453</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/smp: do not decrement idle task preempt count in CPU offline

With PREEMPT_COUNT=y, when a CPU is offlined and then onlined again, we
get:

BUG: scheduling while atomic: swapper/1/0/0x00000000
no locks held by swapper/1/0.
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.15.0-rc2+ #100
Call Trace:
 dump_stack_lvl+0xac/0x108
 __schedule_bug+0xac/0xe0
 __schedule+0xcf8/0x10d0
 schedule_idle+0x3c/0x70
 do_idle+0x2d8/0x4a0
 cpu_startup_entry+0x38/0x40
 start_secondary+0x2ec/0x3a0
 start_secondary_prolog+0x10/0x14

This is because powerpc's arch_cpu_idle_dead() decrements the idle task's
preempt count, for reasons explained in commit a7c2bb8279d2 ("powerpc:
Re-enable preemption before cpu_die()"), specifically "start_secondary()
expects a preempt_count() of 0."

However, since commit 2c669ef6979c ("powerpc/preempt: Don't touch the idle
task's preempt_count during hotplug") and commit f1a0a376ca0c ("sched/core:
Initialize the idle task with preemption disabled"), that justification no
longer holds.

The idle task isn't supposed to re-enable preemption, so remove the
vestigial preempt_enable() from the CPU offline path.

Tested with pseries and powernv in qemu, and pseries on PowerVM.</Note>
    </Notes>
    <CVE>CVE-2021-47454</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ptp: Fix possible memory leak in ptp_clock_register()

I got memory leak as follows when doing fault injection test:

unreferenced object 0xffff88800906c618 (size 8):
  comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s)
  hex dump (first 8 bytes):
    70 74 70 30 00 00 00 00                          ptp0....
  backtrace:
    [&lt;00000000312ed458&gt;] __kmalloc_track_caller+0x19f/0x3a0
    [&lt;0000000079f6e2ff&gt;] kvasprintf+0xb5/0x150
    [&lt;0000000026aae54f&gt;] kvasprintf_const+0x60/0x190
    [&lt;00000000f323a5f7&gt;] kobject_set_name_vargs+0x56/0x150
    [&lt;000000004e35abdd&gt;] dev_set_name+0xc0/0x100
    [&lt;00000000f20cfe25&gt;] ptp_clock_register+0x9f4/0xd30 [ptp]
    [&lt;000000008bb9f0de&gt;] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]

When posix_clock_register() returns an error, the name allocated
in dev_set_name() will be leaked, the put_device() should be used
to give up the device reference, then the name will be freed in
kobject_cleanup() and other memory will be freed in ptp_clock_release().</Note>
    </Notes>
    <CVE>CVE-2021-47455</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: isotp: isotp_sendmsg(): add result check for wait_event_interruptible()

Using wait_event_interruptible() to wait for complete transmission,
but do not check the result of wait_event_interruptible() which can be
interrupted. It will result in TX buffer has multiple accessors and
the later process interferes with the previous process.

Following is one of the problems reported by syzbot.

=============================================================
WARNING: CPU: 0 PID: 0 at net/can/isotp.c:840 isotp_tx_timer_handler+0x2e0/0x4c0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc7+ #68
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014
RIP: 0010:isotp_tx_timer_handler+0x2e0/0x4c0
Call Trace:
 &lt;IRQ&gt;
 ? isotp_setsockopt+0x390/0x390
 __hrtimer_run_queues+0xb8/0x610
 hrtimer_run_softirq+0x91/0xd0
 ? rcu_read_lock_sched_held+0x4d/0x80
 __do_softirq+0xe8/0x553
 irq_exit_rcu+0xf8/0x100
 sysvec_apic_timer_interrupt+0x9e/0xc0
 &lt;/IRQ&gt;
 asm_sysvec_apic_timer_interrupt+0x12/0x20

Add result check for wait_event_interruptible() in isotp_sendmsg()
to avoid multiple accessers for tx buffer.</Note>
    </Notes>
    <CVE>CVE-2021-47457</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: j1939: j1939_netdev_start(): fix UAF for rx_kref of j1939_priv

It will trigger UAF for rx_kref of j1939_priv as following.

        cpu0                                    cpu1
j1939_sk_bind(socket0, ndev0, ...)
j1939_netdev_start
                                        j1939_sk_bind(socket1, ndev0, ...)
                                        j1939_netdev_start
j1939_priv_set
                                        j1939_priv_get_by_ndev_locked
j1939_jsk_add
.....
j1939_netdev_stop
kref_put_lock(&amp;priv-&gt;rx_kref, ...)
                                        kref_get(&amp;priv-&gt;rx_kref, ...)
                                        REFCOUNT_WARN("addition on 0;...")

====================================================
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 1 PID: 20874 at lib/refcount.c:25 refcount_warn_saturate+0x169/0x1e0
RIP: 0010:refcount_warn_saturate+0x169/0x1e0
Call Trace:
 j1939_netdev_start+0x68b/0x920
 j1939_sk_bind+0x426/0xeb0
 ? security_socket_bind+0x83/0xb0

The rx_kref's kref_get() and kref_put() should use j1939_netdev_lock to
protect.</Note>
    </Notes>
    <CVE>CVE-2021-47459</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

userfaultfd: fix a race between writeprotect and exit_mmap()

A race is possible when a process exits, its VMAs are removed by
exit_mmap() and at the same time userfaultfd_writeprotect() is called.

The race was detected by KASAN on a development kernel, but it appears
to be possible on vanilla kernels as well.

Use mmget_not_zero() to prevent the race as done in other userfaultfd
operations.</Note>
    </Notes>
    <CVE>CVE-2021-47461</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/mempolicy: do not allow illegal MPOL_F_NUMA_BALANCING | MPOL_LOCAL in mbind()

syzbot reported access to unitialized memory in mbind() [1]

Issue came with commit bda420b98505 ("numa balancing: migrate on fault
among multiple bound nodes")

This commit added a new bit in MPOL_MODE_FLAGS, but only checked valid
combination (MPOL_F_NUMA_BALANCING can only be used with MPOL_BIND) in
do_set_mempolicy()

This patch moves the check in sanitize_mpol_flags() so that it is also
used by mbind()

  [1]
  BUG: KMSAN: uninit-value in __mpol_equal+0x567/0x590 mm/mempolicy.c:2260
   __mpol_equal+0x567/0x590 mm/mempolicy.c:2260
   mpol_equal include/linux/mempolicy.h:105 [inline]
   vma_merge+0x4a1/0x1e60 mm/mmap.c:1190
   mbind_range+0xcc8/0x1e80 mm/mempolicy.c:811
   do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333
   kernel_mbind mm/mempolicy.c:1483 [inline]
   __do_sys_mbind mm/mempolicy.c:1490 [inline]
   __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486
   __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486
   do_syscall_x64 arch/x86/entry/common.c:51 [inline]
   do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
   entry_SYSCALL_64_after_hwframe+0x44/0xae

  Uninit was created at:
   slab_alloc_node mm/slub.c:3221 [inline]
   slab_alloc mm/slub.c:3230 [inline]
   kmem_cache_alloc+0x751/0xff0 mm/slub.c:3235
   mpol_new mm/mempolicy.c:293 [inline]
   do_mbind+0x912/0x15f0 mm/mempolicy.c:1289
   kernel_mbind mm/mempolicy.c:1483 [inline]
   __do_sys_mbind mm/mempolicy.c:1490 [inline]
   __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486
   __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486
   do_syscall_x64 arch/x86/entry/common.c:51 [inline]
   do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
   entry_SYSCALL_64_after_hwframe+0x44/0xae
  =====================================================
  Kernel panic - not syncing: panic_on_kmsan set ...
  CPU: 0 PID: 15049 Comm: syz-executor.0 Tainted: G    B             5.15.0-rc2-syzkaller #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
  Call Trace:
   __dump_stack lib/dump_stack.c:88 [inline]
   dump_stack_lvl+0x1ff/0x28e lib/dump_stack.c:106
   dump_stack+0x25/0x28 lib/dump_stack.c:113
   panic+0x44f/0xdeb kernel/panic.c:232
   kmsan_report+0x2ee/0x300 mm/kmsan/report.c:186
   __msan_warning+0xd7/0x150 mm/kmsan/instrumentation.c:208
   __mpol_equal+0x567/0x590 mm/mempolicy.c:2260
   mpol_equal include/linux/mempolicy.h:105 [inline]
   vma_merge+0x4a1/0x1e60 mm/mmap.c:1190
   mbind_range+0xcc8/0x1e80 mm/mempolicy.c:811
   do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333
   kernel_mbind mm/mempolicy.c:1483 [inline]
   __do_sys_mbind mm/mempolicy.c:1490 [inline]
   __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486
   __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486
   do_syscall_x64 arch/x86/entry/common.c:51 [inline]
   do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
   entry_SYSCALL_64_after_hwframe+0x44/0xae</Note>
    </Notes>
    <CVE>CVE-2021-47462</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/secretmem: fix NULL page-&gt;mapping dereference in page_is_secretmem()

Check for a NULL page-&gt;mapping before dereferencing the mapping in
page_is_secretmem(), as the page's mapping can be nullified while gup()
is running, e.g.  by reclaim or truncation.

  BUG: kernel NULL pointer dereference, address: 0000000000000068
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] PREEMPT SMP NOPTI
  CPU: 6 PID: 4173897 Comm: CPU 3/KVM Tainted: G        W
  RIP: 0010:internal_get_user_pages_fast+0x621/0x9d0
  Code: &lt;48&gt; 81 7a 68 80 08 04 bc 0f 85 21 ff ff 8 89 c7 be
  RSP: 0018:ffffaa90087679b0 EFLAGS: 00010046
  RAX: ffffe3f37905b900 RBX: 00007f2dd561e000 RCX: ffffe3f37905b934
  RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffe3f37905b900
  ...
  CR2: 0000000000000068 CR3: 00000004c5898003 CR4: 00000000001726e0
  Call Trace:
   get_user_pages_fast_only+0x13/0x20
   hva_to_pfn+0xa9/0x3e0
   try_async_pf+0xa1/0x270
   direct_page_fault+0x113/0xad0
   kvm_mmu_page_fault+0x69/0x680
   vmx_handle_exit+0xe1/0x5d0
   kvm_arch_vcpu_ioctl_run+0xd81/0x1c70
   kvm_vcpu_ioctl+0x267/0x670
   __x64_sys_ioctl+0x83/0xa0
   do_syscall_64+0x56/0x80
   entry_SYSCALL_64_after_hwframe+0x44/0xae</Note>
    </Notes>
    <CVE>CVE-2021-47463</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix possible null-pointer dereference in audit_filter_rules

Fix  possible null-pointer dereference in audit_filter_rules.

audit_filter_rules() error: we previously assumed 'ctx' could be null</Note>
    </Notes>
    <CVE>CVE-2021-47464</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm, slub: fix potential memoryleak in kmem_cache_open()

In error path, the random_seq of slub cache might be leaked.  Fix this
by using __kmem_cache_release() to release all the relevant resources.</Note>
    </Notes>
    <CVE>CVE-2021-47466</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

kunit: fix reference count leak in kfree_at_end

The reference counting issue happens in the normal path of
kfree_at_end(). When kunit_alloc_and_get_resource() is invoked, the
function forgets to handle the returned resource object, whose refcount
increased inside, causing a refcount leak.

Fix this issue by calling kunit_alloc_resource() instead of
kunit_alloc_and_get_resource().

Fixed the following when applying:
Shuah Khan &lt;skhan@linuxfoundation.org&gt;

CHECK: Alignment should match open parenthesis
+	kunit_alloc_resource(test, NULL, kfree_res_free, GFP_KERNEL,
 				     (void *)to_free);</Note>
    </Notes>
    <CVE>CVE-2021-47467</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

isdn: mISDN: Fix sleeping function called from invalid context

The driver can call card-&gt;isac.release() function from an atomic
context.

Fix this by calling this function after releasing the lock.

The following log reveals it:

[   44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018
[   44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe
[   44.169574 ] INFO: lockdep is turned off.
[   44.169899 ] irq event stamp: 0
[   44.170160 ] hardirqs last  enabled at (0): [&lt;0000000000000000&gt;] 0x0
[   44.170627 ] hardirqs last disabled at (0): [&lt;ffffffff814209ed&gt;] copy_process+0x132d/0x3e00
[   44.171240 ] softirqs last  enabled at (0): [&lt;ffffffff81420a1a&gt;] copy_process+0x135a/0x3e00
[   44.171852 ] softirqs last disabled at (0): [&lt;0000000000000000&gt;] 0x0
[   44.172318 ] Preemption disabled at:
[   44.172320 ] [&lt;ffffffffa009b0a9&gt;] nj_release+0x69/0x500 [netjet]
[   44.174441 ] Call Trace:
[   44.174630 ]  dump_stack_lvl+0xa8/0xd1
[   44.174912 ]  dump_stack+0x15/0x17
[   44.175166 ]  ___might_sleep+0x3a2/0x510
[   44.175459 ]  ? nj_release+0x69/0x500 [netjet]
[   44.175791 ]  __might_sleep+0x82/0xe0
[   44.176063 ]  ? start_flush_work+0x20/0x7b0
[   44.176375 ]  start_flush_work+0x33/0x7b0
[   44.176672 ]  ? trace_irq_enable_rcuidle+0x85/0x170
[   44.177034 ]  ? kasan_quarantine_put+0xaa/0x1f0
[   44.177372 ]  ? kasan_quarantine_put+0xaa/0x1f0
[   44.177711 ]  __flush_work+0x11a/0x1a0
[   44.177991 ]  ? flush_work+0x20/0x20
[   44.178257 ]  ? lock_release+0x13c/0x8f0
[   44.178550 ]  ? __kasan_check_write+0x14/0x20
[   44.178872 ]  ? do_raw_spin_lock+0x148/0x360
[   44.179187 ]  ? read_lock_is_recursive+0x20/0x20
[   44.179530 ]  ? __kasan_check_read+0x11/0x20
[   44.179846 ]  ? do_raw_spin_unlock+0x55/0x900
[   44.180168 ]  ? ____kasan_slab_free+0x116/0x140
[   44.180505 ]  ? _raw_spin_unlock_irqrestore+0x41/0x60
[   44.180878 ]  ? skb_queue_purge+0x1a3/0x1c0
[   44.181189 ]  ? kfree+0x13e/0x290
[   44.181438 ]  flush_work+0x17/0x20
[   44.181695 ]  mISDN_freedchannel+0xe8/0x100
[   44.182006 ]  isac_release+0x210/0x260 [mISDNipac]
[   44.182366 ]  nj_release+0xf6/0x500 [netjet]
[   44.182685 ]  nj_remove+0x48/0x70 [netjet]
[   44.182989 ]  pci_device_remove+0xa9/0x250</Note>
    </Notes>
    <CVE>CVE-2021-47468</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix deadlock when adding SPI controllers on SPI buses

Currently we have a global spi_add_lock which we take when adding new
devices so that we can check that we're not trying to reuse a chip
select that's already controlled.  This means that if the SPI device is
itself a SPI controller and triggers the instantiation of further SPI
devices we trigger a deadlock as we try to register and instantiate
those devices while in the process of doing so for the parent controller
and hence already holding the global spi_add_lock.  Since we only care
about concurrency within a single SPI bus move the lock to be per
controller, avoiding the deadlock.

This can be easily triggered in the case of spi-mux.</Note>
    </Notes>
    <CVE>CVE-2021-47469</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm, slub: fix potential use-after-free in slab_debugfs_fops

When sysfs_slab_add failed, we shouldn't call debugfs_slab_add() for s
because s will be freed soon.  And slab_debugfs_fops will use s later
leading to a use-after-free.</Note>
    </Notes>
    <CVE>CVE-2021-47470</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mxsfb: Fix NULL pointer dereference crash on unload

The mxsfb-&gt;crtc.funcs may already be NULL when unloading the driver,
in which case calling mxsfb_irq_disable() via drm_irq_uninstall() from
mxsfb_unload() leads to NULL pointer dereference.

Since all we care about is masking the IRQ and mxsfb-&gt;base is still
valid, just use that to clear and mask the IRQ.</Note>
    </Notes>
    <CVE>CVE-2021-47471</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: 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"/>
    </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:

comedi: vmk80xx: fix bulk-buffer overflow

The driver is using endpoint-sized buffers but must not assume that the
tx and rx buffers are of equal size or a malicious device could overflow
the slab-allocated receive buffer when doing bulk transfers.</Note>
    </Notes>
    <CVE>CVE-2021-47474</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

comedi: vmk80xx: fix transfer-buffer overflows

The driver uses endpoint-sized USB transfer buffers but up until
recently had no sanity checks on the sizes.

Commit e1f13c879a7c ("staging: comedi: check validity of wMaxPacketSize
of usb endpoints found") inadvertently fixed NULL-pointer dereferences
when accessing the transfer buffers in case a malicious device has a
zero wMaxPacketSize.

Make sure to allocate buffers large enough to handle also the other
accesses that are done without a size check (e.g. byte 18 in
vmk80xx_cnt_insn_read() for the VMK8061_MODEL) to avoid writing beyond
the buffers, for example, when doing descriptor fuzzing.

The original driver was for a low-speed device with 8-byte buffers.
Support was later added for a device that uses bulk transfers and is
presumably a full-speed device with a maximum 64-byte wMaxPacketSize.</Note>
    </Notes>
    <CVE>CVE-2021-47475</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

comedi: ni_usb6501: fix NULL-deref in command paths

The driver uses endpoint-sized USB transfer buffers but had no sanity
checks on the sizes. This can lead to zero-size-pointer dereferences or
overflowed transfer buffers in ni6501_port_command() and
ni6501_counter_command() if a (malicious) device has smaller max-packet
sizes than expected (or when doing descriptor fuzz testing).

Add the missing sanity checks to probe().</Note>
    </Notes>
    <CVE>CVE-2021-47476</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

comedi: dt9812: fix DMA buffers on stack

USB transfer buffers are typically mapped for DMA and must not be
allocated on the stack or transfers will fail.

Allocate proper transfer buffers in the various command helpers and
return an error on short transfers instead of acting on random stack
data.

Note that this also fixes a stack info leak on systems where DMA is not
used as 32 bytes are always sent to the device regardless of how short
the command is.</Note>
    </Notes>
    <CVE>CVE-2021-47477</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rtl8712: fix use-after-free in rtl8712_dl_fw

Syzbot reported use-after-free in rtl8712_dl_fw(). The problem was in
race condition between r871xu_dev_remove() -&gt;ndo_open() callback.

It's easy to see from crash log, that driver accesses released firmware
in -&gt;ndo_open() callback. It may happen, since driver was releasing
firmware _before_ unregistering netdev. Fix it by moving
unregister_netdev() before cleaning up resources.

Call Trace:
...
 rtl871x_open_fw drivers/staging/rtl8712/hal_init.c:83 [inline]
 rtl8712_dl_fw+0xd95/0xe10 drivers/staging/rtl8712/hal_init.c:170
 rtl8712_hal_init drivers/staging/rtl8712/hal_init.c:330 [inline]
 rtl871x_hal_init+0xae/0x180 drivers/staging/rtl8712/hal_init.c:394
 netdev_open+0xe6/0x6c0 drivers/staging/rtl8712/os_intfs.c:380
 __dev_open+0x2bc/0x4d0 net/core/dev.c:1484

Freed by task 1306:
...
 release_firmware+0x1b/0x30 drivers/base/firmware_loader/main.c:1053
 r871xu_dev_remove+0xcc/0x2c0 drivers/staging/rtl8712/usb_intf.c:599
 usb_unbind_interface+0x1d8/0x8d0 drivers/usb/core/driver.c:458</Note>
    </Notes>
    <CVE>CVE-2021-47479</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Initialize the ODP xarray when creating an ODP MR

Normally the zero fill would hide the missing initialization, but an
errant set to desc_size in reg_create() causes a crash:

  BUG: unable to handle page fault for address: 0000000800000000
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP PTI
  CPU: 5 PID: 890 Comm: ib_write_bw Not tainted 5.15.0-rc4+ #47
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
  RIP: 0010:mlx5_ib_dereg_mr+0x14/0x3b0 [mlx5_ib]
  Code: 48 63 cd 4c 89 f7 48 89 0c 24 e8 37 30 03 e1 48 8b 0c 24 eb a0 90 0f 1f 44 00 00 41 56 41 55 41 54 55 53 48 89 fb 48 83 ec 30 &lt;48&gt; 8b 2f 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 8b 87 c8
  RSP: 0018:ffff88811afa3a60 EFLAGS: 00010286
  RAX: 000000000000001c RBX: 0000000800000000 RCX: 0000000000000000
  RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000800000000
  RBP: 0000000800000000 R08: 0000000000000000 R09: c0000000fffff7ff
  R10: ffff88811afa38f8 R11: ffff88811afa38f0 R12: ffffffffa02c7ac0
  R13: 0000000000000000 R14: ffff88811afa3cd8 R15: ffff88810772fa00
  FS:  00007f47b9080740(0000) GS:ffff88852cd40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000800000000 CR3: 000000010761e003 CR4: 0000000000370ea0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   mlx5_ib_free_odp_mr+0x95/0xc0 [mlx5_ib]
   mlx5_ib_dereg_mr+0x128/0x3b0 [mlx5_ib]
   ib_dereg_mr_user+0x45/0xb0 [ib_core]
   ? xas_load+0x8/0x80
   destroy_hw_idr_uobject+0x1a/0x50 [ib_uverbs]
   uverbs_destroy_uobject+0x2f/0x150 [ib_uverbs]
   uobj_destroy+0x3c/0x70 [ib_uverbs]
   ib_uverbs_cmd_verbs+0x467/0xb00 [ib_uverbs]
   ? uverbs_finalize_object+0x60/0x60 [ib_uverbs]
   ? ttwu_queue_wakelist+0xa9/0xe0
   ? pty_write+0x85/0x90
   ? file_tty_write.isra.33+0x214/0x330
   ? process_echoes+0x60/0x60
   ib_uverbs_ioctl+0xa7/0x110 [ib_uverbs]
   __x64_sys_ioctl+0x10d/0x8e0
   ? vfs_write+0x17f/0x260
   do_syscall_64+0x3c/0x80
   entry_SYSCALL_64_after_hwframe+0x44/0xae

Add the missing xarray initialization and remove the desc_size set.</Note>
    </Notes>
    <CVE>CVE-2021-47481</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: batman-adv: fix error handling

Syzbot reported ODEBUG warning in batadv_nc_mesh_free(). The problem was
in wrong error handling in batadv_mesh_init().

Before this patch batadv_mesh_init() was calling batadv_mesh_free() in case
of any batadv_*_init() calls failure. This approach may work well, when
there is some kind of indicator, which can tell which parts of batadv are
initialized; but there isn't any.

All written above lead to cleaning up uninitialized fields. Even if we hide
ODEBUG warning by initializing bat_priv-&gt;nc.work, syzbot was able to hit
GPF in batadv_nc_purge_paths(), because hash pointer in still NULL. [1]

To fix these bugs we can unwind batadv_*_init() calls one by one.
It is good approach for 2 reasons: 1) It fixes bugs on error handling
path 2) It improves the performance, since we won't call unneeded
batadv_*_free() functions.

So, this patch makes all batadv_*_init() clean up all allocated memory
before returning with an error to no call correspoing batadv_*_free()
and open-codes batadv_mesh_free() with proper order to avoid touching
uninitialized fields.</Note>
    </Notes>
    <CVE>CVE-2021-47482</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

octeontx2-af: Fix possible null pointer dereference.

This patch fixes possible null pointer dereference in files
"rvu_debugfs.c" and "rvu_nix.c"</Note>
    </Notes>
    <CVE>CVE-2021-47484</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

riscv, bpf: Fix potential NULL dereference

The bpf_jit_binary_free() function requires a non-NULL argument. When
the RISC-V BPF JIT fails to converge in NR_JIT_ITERATIONS steps,
jit_data-&gt;header will be NULL, which triggers a NULL
dereference. Avoid this by checking the argument, prior calling the
function.</Note>
    </Notes>
    <CVE>CVE-2021-47486</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-47488</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ttm: fix memleak in ttm_transfered_destroy

We need to cleanup the fences for ghost objects as well.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214029
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214447</Note>
    </Notes>
    <CVE>CVE-2021-47490</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 race between searching chunks and release journal_head from buffer_head

Encountered a race between ocfs2_test_bg_bit_allocatable() and
jbd2_journal_put_journal_head() resulting in the below vmcore.

  PID: 106879  TASK: ffff880244ba9c00  CPU: 2   COMMAND: "loop3"
  Call trace:
    panic
    oops_end
    no_context
    __bad_area_nosemaphore
    bad_area_nosemaphore
    __do_page_fault
    do_page_fault
    page_fault
      [exception RIP: ocfs2_block_group_find_clear_bits+316]
    ocfs2_block_group_find_clear_bits [ocfs2]
    ocfs2_cluster_group_search [ocfs2]
    ocfs2_search_chain [ocfs2]
    ocfs2_claim_suballoc_bits [ocfs2]
    __ocfs2_claim_clusters [ocfs2]
    ocfs2_claim_clusters [ocfs2]
    ocfs2_local_alloc_slide_window [ocfs2]
    ocfs2_reserve_local_alloc_bits [ocfs2]
    ocfs2_reserve_clusters_with_limit [ocfs2]
    ocfs2_reserve_clusters [ocfs2]
    ocfs2_lock_refcount_allocators [ocfs2]
    ocfs2_make_clusters_writable [ocfs2]
    ocfs2_replace_cow [ocfs2]
    ocfs2_refcount_cow [ocfs2]
    ocfs2_file_write_iter [ocfs2]
    lo_rw_aio
    loop_queue_work
    kthread_worker_fn
    kthread
    ret_from_fork

When ocfs2_test_bg_bit_allocatable() called bh2jh(bg_bh), the
bg_bh-&gt;b_private NULL as jbd2_journal_put_journal_head() raced and
released the jounal head from the buffer head.  Needed to take bit lock
for the bit 'BH_JournalHead' to fix this race.</Note>
    </Notes>
    <CVE>CVE-2021-47493</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cfg80211: fix management registrations locking

The management registrations locking was broken, the list was
locked for each wdev, but cfg80211_mgmt_registrations_update()
iterated it without holding all the correct spinlocks, causing
list corruption.

Rather than trying to fix it with fine-grained locking, just
move the lock to the wiphy/rdev (still need the list on each
wdev), we already need to hold the wdev lock to change it, so
there's no contention on the lock in any case. This trivially
fixes the bug since we hold one wdev's lock already, and now
will hold the lock that protects all lists.</Note>
    </Notes>
    <CVE>CVE-2021-47494</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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/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"/>
    </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:

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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: accel: kxcjk-1013: Fix possible memory leak in probe and remove

When ACPI type is ACPI_SMO8500, the data-&gt;dready_trig will not be set, the
memory allocated by iio_triggered_buffer_setup() will not be freed, and cause
memory leak as follows:

unreferenced object 0xffff888009551400 (size 512):
  comm "i2c-SMO8500-125", pid 911, jiffies 4294911787 (age 83.852s)
  hex dump (first 32 bytes):
    02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff  ........ .......
  backtrace:
    [&lt;0000000041ce75ee&gt;] kmem_cache_alloc_trace+0x16d/0x360
    [&lt;000000000aeb17b0&gt;] iio_kfifo_allocate+0x41/0x130 [kfifo_buf]
    [&lt;000000004b40c1f5&gt;] iio_triggered_buffer_setup_ext+0x2c/0x210 [industrialio_triggered_buffer]
    [&lt;000000004375b15f&gt;] kxcjk1013_probe+0x10c3/0x1d81 [kxcjk_1013]

Fix it by remove data-&gt;dready_trig condition in probe and remove.</Note>
    </Notes>
    <CVE>CVE-2021-47499</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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 NULL pointer dereference in i40e_dbg_dump_desc

When trying to dump VFs VSI RX/TX descriptors
using debugfs there was a crash
due to NULL pointer dereference in i40e_dbg_dump_desc.
Added a check to i40e_dbg_dump_desc that checks if
VSI type is correct for dumping RX/TX descriptors.</Note>
    </Notes>
    <CVE>CVE-2021-47501</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ASoC: codecs: wcd934x: handle channel mappping list correctly

Currently each channel is added as list to dai channel list, however
there is danger of adding same channel to multiple dai channel list
which endups corrupting the other list where its already added.

This patch ensures that the channel is actually free before adding to
the dai channel list and also ensures that the channel is on the list
before deleting it.

This check was missing previously, and we did not hit this issue as
we were testing very simple usecases with sequence of amixer commands.</Note>
    </Notes>
    <CVE>CVE-2021-47502</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: pm80xx: Do not call scsi_remove_host() in pm8001_alloc()

Calling scsi_remove_host() before scsi_add_host() results in a crash:

 BUG: kernel NULL pointer dereference, address: 0000000000000108
 RIP: 0010:device_del+0x63/0x440
 Call Trace:
  device_unregister+0x17/0x60
  scsi_remove_host+0xee/0x2a0
  pm8001_pci_probe+0x6ef/0x1b90 [pm80xx]
  local_pci_probe+0x3f/0x90

We cannot call scsi_remove_host() in pm8001_alloc() because scsi_add_host()
has not been called yet at that point in time.

Function call tree:

  pm8001_pci_probe()
  |
  `- pm8001_pci_alloc()
  |  |
  |  `- pm8001_alloc()
  |     |
  |     `- scsi_remove_host()
  |
  `- scsi_add_host()</Note>
    </Notes>
    <CVE>CVE-2021-47503</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

io_uring: ensure task_work gets run as part of cancelations

If we successfully cancel a work item but that work item needs to be
processed through task_work, then we can be sleeping uninterruptibly
in io_uring_cancel_generic() and never process it. Hence we don't
make forward progress and we end up with an uninterruptible sleep
warning.

While in there, correct a comment that should be IFF, not IIF.</Note>
    </Notes>
    <CVE>CVE-2021-47504</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 nsfd startup race (again)

Commit bd5ae9288d64 ("nfsd: register pernet ops last, unregister first")
has re-opened rpc_pipefs_event() race against nfsd_net_id registration
(register_pernet_subsys()) which has been fixed by commit bb7ffbf29e76
("nfsd: fix nsfd startup race triggering BUG_ON").

Restore the order of register_pernet_subsys() vs register_cld_notifier().
Add WARN_ON() to prevent a future regression.

Crash info:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000012
CPU: 8 PID: 345 Comm: mount Not tainted 5.4.144-... #1
pc : rpc_pipefs_event+0x54/0x120 [nfsd]
lr : rpc_pipefs_event+0x48/0x120 [nfsd]
Call trace:
 rpc_pipefs_event+0x54/0x120 [nfsd]
 blocking_notifier_call_chain
 rpc_fill_super
 get_tree_keyed
 rpc_fs_get_tree
 vfs_get_tree
 do_mount
 ksys_mount
 __arm64_sys_mount
 el0_svc_handler
 el0_svc</Note>
    </Notes>
    <CVE>CVE-2021-47507</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: free exchange changeset on failures

Fstests runs on my VMs have show several kmemleak reports like the following.

  unreferenced object 0xffff88811ae59080 (size 64):
    comm "xfs_io", pid 12124, jiffies 4294987392 (age 6.368s)
    hex dump (first 32 bytes):
      00 c0 1c 00 00 00 00 00 ff cf 1c 00 00 00 00 00  ................
      90 97 e5 1a 81 88 ff ff 90 97 e5 1a 81 88 ff ff  ................
    backtrace:
      [&lt;00000000ac0176d2&gt;] ulist_add_merge+0x60/0x150 [btrfs]
      [&lt;0000000076e9f312&gt;] set_state_bits+0x86/0xc0 [btrfs]
      [&lt;0000000014fe73d6&gt;] set_extent_bit+0x270/0x690 [btrfs]
      [&lt;000000004f675208&gt;] set_record_extent_bits+0x19/0x20 [btrfs]
      [&lt;00000000b96137b1&gt;] qgroup_reserve_data+0x274/0x310 [btrfs]
      [&lt;0000000057e9dcbb&gt;] btrfs_check_data_free_space+0x5c/0xa0 [btrfs]
      [&lt;0000000019c4511d&gt;] btrfs_delalloc_reserve_space+0x1b/0xa0 [btrfs]
      [&lt;000000006d37e007&gt;] btrfs_dio_iomap_begin+0x415/0x970 [btrfs]
      [&lt;00000000fb8a74b8&gt;] iomap_iter+0x161/0x1e0
      [&lt;0000000071dff6ff&gt;] __iomap_dio_rw+0x1df/0x700
      [&lt;000000002567ba53&gt;] iomap_dio_rw+0x5/0x20
      [&lt;0000000072e555f8&gt;] btrfs_file_write_iter+0x290/0x530 [btrfs]
      [&lt;000000005eb3d845&gt;] new_sync_write+0x106/0x180
      [&lt;000000003fb505bf&gt;] vfs_write+0x24d/0x2f0
      [&lt;000000009bb57d37&gt;] __x64_sys_pwrite64+0x69/0xa0
      [&lt;000000003eba3fdf&gt;] do_syscall_64+0x43/0x90

In case brtfs_qgroup_reserve_data() or btrfs_delalloc_reserve_metadata()
fail the allocated extent_changeset will not be freed.

So in btrfs_check_data_free_space() and btrfs_delalloc_reserve_space()
free the allocated extent_changeset to get rid of the allocated memory.

The issue currently only happens in the direct IO write path, but only
after 65b3c08606e5 ("btrfs: fix ENOSPC failure when attempting direct IO
write into NOCOW range"), and also at defrag_one_locked_target(). Every
other place is always calling extent_changeset_free() even if its call
to btrfs_delalloc_reserve_space() or btrfs_check_data_free_space() has
failed.</Note>
    </Notes>
    <CVE>CVE-2021-47508</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 re-dirty process of tree-log nodes

There is a report of a transaction abort of -EAGAIN with the following
script.

  #!/bin/sh

  for d in sda sdb; do
          mkfs.btrfs -d single -m single -f /dev/\${d}
  done

  mount /dev/sda /mnt/test
  mount /dev/sdb /mnt/scratch

  for dir in test scratch; do
          echo 3 &gt;/proc/sys/vm/drop_caches
          fio --directory=/mnt/\${dir} --name=fio.\${dir} --rw=read --size=50G --bs=64m \
                  --numjobs=$(nproc) --time_based --ramp_time=5 --runtime=480 \
                  --group_reporting |&amp; tee /dev/shm/fio.\${dir}
          echo 3 &gt;/proc/sys/vm/drop_caches
  done

  for d in sda sdb; do
          umount /dev/\${d}
  done

The stack trace is shown in below.

  [3310.967991] BTRFS: error (device sda) in btrfs_commit_transaction:2341: errno=-11 unknown (Error while writing out transaction)
  [3310.968060] BTRFS info (device sda): forced readonly
  [3310.968064] BTRFS warning (device sda): Skipping commit of aborted transaction.
  [3310.968065] ------------[ cut here ]------------
  [3310.968066] BTRFS: Transaction aborted (error -11)
  [3310.968074] WARNING: CPU: 14 PID: 1684 at fs/btrfs/transaction.c:1946 btrfs_commit_transaction.cold+0x209/0x2c8
  [3310.968131] CPU: 14 PID: 1684 Comm: fio Not tainted 5.14.10-300.fc35.x86_64 #1
  [3310.968135] Hardware name: DIAWAY Tartu/Tartu, BIOS V2.01.B10 04/08/2021
  [3310.968137] RIP: 0010:btrfs_commit_transaction.cold+0x209/0x2c8
  [3310.968144] RSP: 0018:ffffb284ce393e10 EFLAGS: 00010282
  [3310.968147] RAX: 0000000000000026 RBX: ffff973f147b0f60 RCX: 0000000000000027
  [3310.968149] RDX: ffff974ecf098a08 RSI: 0000000000000001 RDI: ffff974ecf098a00
  [3310.968150] RBP: ffff973f147b0f08 R08: 0000000000000000 R09: ffffb284ce393c48
  [3310.968151] R10: ffffb284ce393c40 R11: ffffffff84f47468 R12: ffff973f101bfc00
  [3310.968153] R13: ffff971f20cf2000 R14: 00000000fffffff5 R15: ffff973f147b0e58
  [3310.968154] FS:  00007efe65468740(0000) GS:ffff974ecf080000(0000) knlGS:0000000000000000
  [3310.968157] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [3310.968158] CR2: 000055691bcbe260 CR3: 000000105cfa4001 CR4: 0000000000770ee0
  [3310.968160] PKRU: 55555554
  [3310.968161] Call Trace:
  [3310.968167]  ? dput+0xd4/0x300
  [3310.968174]  btrfs_sync_file+0x3f1/0x490
  [3310.968180]  __x64_sys_fsync+0x33/0x60
  [3310.968185]  do_syscall_64+0x3b/0x90
  [3310.968190]  entry_SYSCALL_64_after_hwframe+0x44/0xae
  [3310.968194] RIP: 0033:0x7efe6557329b
  [3310.968200] RSP: 002b:00007ffe0236ebc0 EFLAGS: 00000293 ORIG_RAX: 000000000000004a
  [3310.968203] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007efe6557329b
  [3310.968204] RDX: 0000000000000000 RSI: 00007efe58d77010 RDI: 0000000000000006
  [3310.968205] RBP: 0000000004000000 R08: 0000000000000000 R09: 00007efe58d77010
  [3310.968207] R10: 0000000016cacc0c R11: 0000000000000293 R12: 00007efe5ce95980
  [3310.968208] R13: 0000000000000000 R14: 00007efe6447c790 R15: 0000000c80000000
  [3310.968212] ---[ end trace 1a346f4d3c0d96ba ]---
  [3310.968214] BTRFS: error (device sda) in cleanup_transaction:1946: errno=-11 unknown

The abort occurs because of a write hole while writing out freeing tree
nodes of a tree-log tree. For zoned btrfs, we re-dirty a freed tree
node to ensure btrfs can write the region and does not leave a hole on
write on a zoned device. The current code fails to re-dirty a node
when the tree-log tree's depth is greater or equal to 2. That leads to
a transaction abort with -EAGAIN.

Fix the issue by properly re-dirtying a node on walking up the tree.</Note>
    </Notes>
    <CVE>CVE-2021-47510</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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"/>
    </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/sched: fq_pie: prevent dismantle issue

For some reason, fq_pie_destroy() did not copy
working code from pie_destroy() and other qdiscs,
thus causing elusive bug.

Before calling del_timer_sync(&amp;q-&gt;adapt_timer),
we need to ensure timer will not rearm itself.

rcu: INFO: rcu_preempt self-detected stall on CPU
rcu:    0-....: (4416 ticks this GP) idle=60d/1/0x4000000000000000 softirq=10433/10434 fqs=2579
        (t=10501 jiffies g=13085 q=3989)
NMI backtrace for cpu 0
CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 5.16.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 &lt;IRQ&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
 nmi_cpu_backtrace.cold+0x47/0x144 lib/nmi_backtrace.c:111
 nmi_trigger_cpumask_backtrace+0x1b3/0x230 lib/nmi_backtrace.c:62
 trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline]
 rcu_dump_cpu_stacks+0x25e/0x3f0 kernel/rcu/tree_stall.h:343
 print_cpu_stall kernel/rcu/tree_stall.h:627 [inline]
 check_cpu_stall kernel/rcu/tree_stall.h:711 [inline]
 rcu_pending kernel/rcu/tree.c:3878 [inline]
 rcu_sched_clock_irq.cold+0x9d/0x746 kernel/rcu/tree.c:2597
 update_process_times+0x16d/0x200 kernel/time/timer.c:1785
 tick_sched_handle+0x9b/0x180 kernel/time/tick-sched.c:226
 tick_sched_timer+0x1b0/0x2d0 kernel/time/tick-sched.c:1428
 __run_hrtimer kernel/time/hrtimer.c:1685 [inline]
 __hrtimer_run_queues+0x1c0/0xe50 kernel/time/hrtimer.c:1749
 hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811
 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1086 [inline]
 __sysvec_apic_timer_interrupt+0x146/0x530 arch/x86/kernel/apic/apic.c:1103
 sysvec_apic_timer_interrupt+0x8e/0xc0 arch/x86/kernel/apic/apic.c:1097
 &lt;/IRQ&gt;
 &lt;TASK&gt;
 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:638
RIP: 0010:write_comp_data kernel/kcov.c:221 [inline]
RIP: 0010:__sanitizer_cov_trace_const_cmp1+0x1d/0x80 kernel/kcov.c:273
Code: 54 c8 20 48 89 10 c3 66 0f 1f 44 00 00 53 41 89 fb 41 89 f1 bf 03 00 00 00 65 48 8b 0c 25 40 70 02 00 48 89 ce 4c 8b 54 24 08 &lt;e8&gt; 4e f7 ff ff 84 c0 74 51 48 8b 81 88 15 00 00 44 8b 81 84 15 00
RSP: 0018:ffffc90000d27b28 EFLAGS: 00000246
RAX: 0000000000000000 RBX: ffff888064bf1bf0 RCX: ffff888011928000
RDX: ffff888011928000 RSI: ffff888011928000 RDI: 0000000000000003
RBP: ffff888064bf1c28 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff875d8295 R11: 0000000000000000 R12: 0000000000000000
R13: ffff8880783dd300 R14: 0000000000000000 R15: 0000000000000000
 pie_calculate_probability+0x405/0x7c0 net/sched/sch_pie.c:418
 fq_pie_timer+0x170/0x2a0 net/sched/sch_fq_pie.c:383
 call_timer_fn+0x1a5/0x6b0 kernel/time/timer.c:1421
 expire_timers kernel/time/timer.c:1466 [inline]
 __run_timers.part.0+0x675/0xa20 kernel/time/timer.c:1734
 __run_timers kernel/time/timer.c:1715 [inline]
 run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1747
 __do_softirq+0x29b/0x9c2 kernel/softirq.c:558
 run_ksoftirqd kernel/softirq.c:921 [inline]
 run_ksoftirqd+0x2d/0x60 kernel/softirq.c:913
 smpboot_thread_fn+0x645/0x9c0 kernel/smpboot.c:164
 kthread+0x405/0x4f0 kernel/kthread.c:327
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2021-47512</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: dsa: felix: Fix memory leak in felix_setup_mmio_filtering

Avoid a memory leak if there is not a CPU port defined.

Addresses-Coverity-ID: 1492897 ("Resource leak")
Addresses-Coverity-ID: 1492899 ("Resource leak")</Note>
    </Notes>
    <CVE>CVE-2021-47513</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

devlink: fix netns refcount leak in devlink_nl_cmd_reload()

While preparing my patch series adding netns refcount tracking,
I spotted bugs in devlink_nl_cmd_reload()

Some error paths forgot to release a refcount on a netns.

To fix this, we can reduce the scope of get_net()/put_net()
section around the call to devlink_reload().</Note>
    </Notes>
    <CVE>CVE-2021-47514</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfp: Fix memory leak in nfp_cpp_area_cache_add()

In line 800 (#1), nfp_cpp_area_alloc() allocates and initializes a
CPP area structure. But in line 807 (#2), when the cache is allocated
failed, this CPP area structure is not freed, which will result in
memory leak.

We can fix it by freeing the CPP area when the cache is allocated
failed (#2).

792 int nfp_cpp_area_cache_add(struct nfp_cpp *cpp, size_t size)
793 {
794 	struct nfp_cpp_area_cache *cache;
795 	struct nfp_cpp_area *area;

800	area = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0),
801 				  0, size);
	// #1: allocates and initializes

802 	if (!area)
803 		return -ENOMEM;

805 	cache = kzalloc(sizeof(*cache), GFP_KERNEL);
806 	if (!cache)
807 		return -ENOMEM; // #2: missing free

817	return 0;
818 }</Note>
    </Notes>
    <CVE>CVE-2021-47516</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

can: sja1000: fix use after free in ems_pcmcia_add_card()

If the last channel is not available then "dev" is freed.  Fortunately,
we can just use "pdev-&gt;irq" instead.

Also we should check if at least one channel was set up.</Note>
    </Notes>
    <CVE>CVE-2021-47521</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

HID: bigbenff: prevent null pointer dereference

When emulating the device through uhid, there is a chance we don't have
output reports and so report_field is null.</Note>
    </Notes>
    <CVE>CVE-2021-47522</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

serial: liteuart: fix minor-number leak on probe errors

Make sure to release the allocated minor number before returning on
probe errors.</Note>
    </Notes>
    <CVE>CVE-2021-47524</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: liteuart: fix use-after-free and memleak on unbind

Deregister the port when unbinding the driver to prevent it from being
used after releasing the driver data and leaking memory allocated by
serial core.</Note>
    </Notes>
    <CVE>CVE-2021-47525</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

serial: liteuart: Fix NULL pointer dereference in -&gt;remove()

drvdata has to be set in _probe() - otherwise platform_get_drvdata()
causes null pointer dereference BUG in _remove().</Note>
    </Notes>
    <CVE>CVE-2021-47526</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

serial: core: fix transmit-buffer reset and memleak

Commit 761ed4a94582 ("tty: serial_core: convert uart_close to use
tty_port_close") converted serial core to use tty_port_close() but
failed to notice that the transmit buffer still needs to be freed on
final close.

Not freeing the transmit buffer means that the buffer is no longer
cleared on next open so that any ioctl() waiting for the buffer to drain
might wait indefinitely (e.g. on termios changes) or that stale data can
end up being transmitted in case tx is restarted.

Furthermore, the buffer of any port that has been opened would leak on
driver unbind.

Note that the port lock is held when clearing the buffer pointer due to
the ldisc race worked around by commit a5ba1d95e46e ("uart: fix race
between uart_put_char() and uart_shutdown()").

Also note that the tty-port shutdown() callback is not called for
console ports so it is not strictly necessary to free the buffer page
after releasing the lock (cf. d72402145ace ("tty/serial: do not free
trasnmit buffer page under port lock")).</Note>
    </Notes>
    <CVE>CVE-2021-47527</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: cdnsp: Fix a NULL pointer dereference in cdnsp_endpoint_init()

In cdnsp_endpoint_init(), cdnsp_ring_alloc() is assigned to pep-&gt;ring
and there is a dereference of it in cdnsp_endpoint_init(), which could
lead to a NULL pointer dereference on failure of cdnsp_ring_alloc().

Fix this bug by adding a check of pep-&gt;ring.

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_USB_CDNSP_GADGET=y show no new warnings,
and our static analyzer no longer warns about this code.</Note>
    </Notes>
    <CVE>CVE-2021-47528</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iwlwifi: Fix memory leaks in error handling path

Should an error occur (invalid TLV len or memory allocation failure), the
memory already allocated in 'reduce_power_data' should be freed before
returning, otherwise it is leaking.</Note>
    </Notes>
    <CVE>CVE-2021-47529</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 wait_fence submitqueue leak

We weren't dropping the submitqueue reference in all paths.  In
particular, when the fence has already been signalled. Split out
a helper to simplify handling this in the various different return
paths.</Note>
    </Notes>
    <CVE>CVE-2021-47530</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/msm: Fix mmap to include VM_IO and VM_DONTDUMP

In commit 510410bfc034 ("drm/msm: Implement mmap as GEM object
function") we switched to a new/cleaner method of doing things. That's
good, but we missed a little bit.

Before that commit, we used to _first_ run through the
drm_gem_mmap_obj() case where `obj-&gt;funcs-&gt;mmap()` was NULL. That meant
that we ran:

  vma-&gt;vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
  vma-&gt;vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma-&gt;vm_flags));
  vma-&gt;vm_page_prot = pgprot_decrypted(vma-&gt;vm_page_prot);

...and _then_ we modified those mappings with our own. Now that
`obj-&gt;funcs-&gt;mmap()` is no longer NULL we don't run the default
code. It looks like the fact that the vm_flags got VM_IO / VM_DONTDUMP
was important because we're now getting crashes on Chromebooks that
use ARC++ while logging out. Specifically a crash that looks like this
(this is on a 5.10 kernel w/ relevant backports but also seen on a
5.15 kernel):

  Unable to handle kernel paging request at virtual address ffffffc008000000
  Mem abort info:
    ESR = 0x96000006
    EC = 0x25: DABT (current EL), IL = 32 bits
    SET = 0, FnV = 0
    EA = 0, S1PTW = 0
  Data abort info:
    ISV = 0, ISS = 0x00000006
    CM = 0, WnR = 0
  swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000008293d000
  [ffffffc008000000] pgd=00000001002b3003, p4d=00000001002b3003,
                     pud=00000001002b3003, pmd=0000000000000000
  Internal error: Oops: 96000006 [#1] PREEMPT SMP
  [...]
  CPU: 7 PID: 15734 Comm: crash_dump64 Tainted: G W 5.10.67 #1 [...]
  Hardware name: Qualcomm Technologies, Inc. sc7280 IDP SKU2 platform (DT)
  pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
  pc : __arch_copy_to_user+0xc0/0x30c
  lr : copyout+0xac/0x14c
  [...]
  Call trace:
   __arch_copy_to_user+0xc0/0x30c
   copy_page_to_iter+0x1a0/0x294
   process_vm_rw_core+0x240/0x408
   process_vm_rw+0x110/0x16c
   __arm64_sys_process_vm_readv+0x30/0x3c
   el0_svc_common+0xf8/0x250
   do_el0_svc+0x30/0x80
   el0_svc+0x10/0x1c
   el0_sync_handler+0x78/0x108
   el0_sync+0x184/0x1c0
  Code: f8408423 f80008c3 910020c6 36100082 (b8404423)

Let's add the two flags back in.

While we're at it, the fact that we aren't running the default means
that we _don't_ need to clear out VM_PFNMAP, so remove that and save
an instruction.

NOTE: it was confirmed that VM_IO was the important flag to fix the
problem I was seeing, but adding back VM_DONTDUMP seems like a sane
thing to do so I'm doing that too.</Note>
    </Notes>
    <CVE>CVE-2021-47531</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/devfreq: Fix OPP refcnt leak</Note>
    </Notes>
    <CVE>CVE-2021-47532</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/vc4: kms: Clear the HVS FIFO commit pointer once done

Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a
commit") introduced a wait on the previous commit done on a given HVS
FIFO.

However, we never cleared that pointer once done. Since
drm_crtc_commit_put can free the drm_crtc_commit structure directly if
we were the last user, this means that it can lead to a use-after free
if we were to duplicate the state, and that stale pointer would even be
copied to the new state.

Set the pointer to NULL once we're done with the wait so that we don't
carry over a pointer to a free'd structure.</Note>
    </Notes>
    <CVE>CVE-2021-47533</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/vc4: kms: Add missing drm_crtc_commit_put

Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a
commit") introduced a global state for the HVS, with each FIFO storing
the current CRTC commit so that we can properly synchronize commits.

However, the refcounting was off and we thus ended up leaking the
drm_crtc_commit structure every commit. Add a drm_crtc_commit_put to
prevent the leakage.</Note>
    </Notes>
    <CVE>CVE-2021-47534</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/a6xx: Allocate enough space for GMU registers

In commit 142639a52a01 ("drm/msm/a6xx: fix crashstate capture for
A650") we changed a6xx_get_gmu_registers() to read 3 sets of
registers. Unfortunately, we didn't change the memory allocation for
the array. That leads to a KASAN warning (this was on the chromeos-5.4
kernel, which has the problematic commit backported to it):

  BUG: KASAN: slab-out-of-bounds in _a6xx_get_gmu_registers+0x144/0x430
  Write of size 8 at addr ffffff80c89432b0 by task A618-worker/209
  CPU: 5 PID: 209 Comm: A618-worker Tainted: G        W         5.4.156-lockdep #22
  Hardware name: Google Lazor Limozeen without Touchscreen (rev5 - rev8) (DT)
  Call trace:
   dump_backtrace+0x0/0x248
   show_stack+0x20/0x2c
   dump_stack+0x128/0x1ec
   print_address_description+0x88/0x4a0
   __kasan_report+0xfc/0x120
   kasan_report+0x10/0x18
   __asan_report_store8_noabort+0x1c/0x24
   _a6xx_get_gmu_registers+0x144/0x430
   a6xx_gpu_state_get+0x330/0x25d4
   msm_gpu_crashstate_capture+0xa0/0x84c
   recover_worker+0x328/0x838
   kthread_worker_fn+0x32c/0x574
   kthread+0x2dc/0x39c
   ret_from_fork+0x10/0x18

  Allocated by task 209:
   __kasan_kmalloc+0xfc/0x1c4
   kasan_kmalloc+0xc/0x14
   kmem_cache_alloc_trace+0x1f0/0x2a0
   a6xx_gpu_state_get+0x164/0x25d4
   msm_gpu_crashstate_capture+0xa0/0x84c
   recover_worker+0x328/0x838
   kthread_worker_fn+0x32c/0x574
   kthread+0x2dc/0x39c
   ret_from_fork+0x10/0x18</Note>
    </Notes>
    <CVE>CVE-2021-47535</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/smc: fix wrong list_del in smc_lgr_cleanup_early

smc_lgr_cleanup_early() meant to delete the link
group from the link group list, but it deleted
the list head by mistake.

This may cause memory corruption since we didn't
remove the real link group from the list and later
memseted the link group structure.
We got a list corruption panic when testing:

[   231.277259] list_del corruption. prev-&gt;next should be ffff8881398a8000, but was 0000000000000000
[   231.278222] ------------[ cut here ]------------
[   231.278726] kernel BUG at lib/list_debug.c:53!
[   231.279326] invalid opcode: 0000 [#1] SMP NOPTI
[   231.279803] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.46+ #435
[   231.280466] Hardware name: Alibaba Cloud ECS, BIOS 8c24b4c 04/01/2014
[   231.281248] Workqueue: events smc_link_down_work
[   231.281732] RIP: 0010:__list_del_entry_valid+0x70/0x90
[   231.282258] Code: 4c 60 82 e8 7d cc 6a 00 0f 0b 48 89 fe 48 c7 c7 88 4c
60 82 e8 6c cc 6a 00 0f 0b 48 89 fe 48 c7 c7 c0 4c 60 82 e8 5b cc 6a 00 &lt;0f&gt;
0b 48 89 fe 48 c7 c7 00 4d 60 82 e8 4a cc 6a 00 0f 0b cc cc cc
[   231.284146] RSP: 0018:ffffc90000033d58 EFLAGS: 00010292
[   231.284685] RAX: 0000000000000054 RBX: ffff8881398a8000 RCX: 0000000000000000
[   231.285415] RDX: 0000000000000001 RSI: ffff88813bc18040 RDI: ffff88813bc18040
[   231.286141] RBP: ffffffff8305ad40 R08: 0000000000000003 R09: 0000000000000001
[   231.286873] R10: ffffffff82803da0 R11: ffffc90000033b90 R12: 0000000000000001
[   231.287606] R13: 0000000000000000 R14: ffff8881398a8000 R15: 0000000000000003
[   231.288337] FS:   0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
[   231.289160] CS:   0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   231.289754] CR2: 0000000000e72058 CR3: 000000010fa96006 CR4: 00000000003706f0
[   231.290485] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   231.291211] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   231.291940] Call Trace:
[   231.292211]   smc_lgr_terminate_sched+0x53/0xa0
[   231.292677]   smc_switch_conns+0x75/0x6b0
[   231.293085]   ? update_load_avg+0x1a6/0x590
[   231.293517]   ? ttwu_do_wakeup+0x17/0x150
[   231.293907]   ? update_load_avg+0x1a6/0x590
[   231.294317]   ? newidle_balance+0xca/0x3d0
[   231.294716]   smcr_link_down+0x50/0x1a0
[   231.295090]   ? __wake_up_common_lock+0x77/0x90
[   231.295534]   smc_link_down_work+0x46/0x60
[   231.295933]   process_one_work+0x18b/0x350</Note>
    </Notes>
    <CVE>CVE-2021-47536</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

octeontx2-af: Fix a memleak bug in rvu_mbox_init()

In rvu_mbox_init(), mbox_regions is not freed or passed out
under the switch-default region, which could lead to a memory leak.

Fix this bug by changing 'return err' to 'goto free_regions'.

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_OCTEONTX2_AF=y show no new warnings,
and our static analyzer no longer warns about this code.</Note>
    </Notes>
    <CVE>CVE-2021-47537</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7915: fix NULL pointer dereference in mt7915_get_phy_mode

Fix the following NULL pointer dereference in mt7915_get_phy_mode
routine adding an ibss interface to the mt7915 driver.

[  101.137097] wlan0: Trigger new scan to find an IBSS to join
[  102.827039] wlan0: Creating new IBSS network, BSSID 26:a4:50:1a:6e:69
[  103.064756] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[  103.073670] Mem abort info:
[  103.076520]   ESR = 0x96000005
[  103.079614]   EC = 0x25: DABT (current EL), IL = 32 bits
[  103.084934]   SET = 0, FnV = 0
[  103.088042]   EA = 0, S1PTW = 0
[  103.091215] Data abort info:
[  103.094104]   ISV = 0, ISS = 0x00000005
[  103.098041]   CM = 0, WnR = 0
[  103.101044] user pgtable: 4k pages, 39-bit VAs, pgdp=00000000460b1000
[  103.107565] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
[  103.116590] Internal error: Oops: 96000005 [#1] SMP
[  103.189066] CPU: 1 PID: 333 Comm: kworker/u4:3 Not tainted 5.10.75 #0
[  103.195498] Hardware name: MediaTek MT7622 RFB1 board (DT)
[  103.201124] Workqueue: phy0 ieee80211_iface_work [mac80211]
[  103.206695] pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--)
[  103.212705] pc : mt7915_get_phy_mode+0x68/0x120 [mt7915e]
[  103.218103] lr : mt7915_mcu_add_bss_info+0x11c/0x760 [mt7915e]
[  103.223927] sp : ffffffc011cdb9e0
[  103.227235] x29: ffffffc011cdb9e0 x28: ffffff8006563098
[  103.232545] x27: ffffff8005f4da22 x26: ffffff800685ac40
[  103.237855] x25: 0000000000000001 x24: 000000000000011f
[  103.243165] x23: ffffff8005f4e260 x22: ffffff8006567918
[  103.248475] x21: ffffff8005f4df80 x20: ffffff800685ac58
[  103.253785] x19: ffffff8006744400 x18: 0000000000000000
[  103.259094] x17: 0000000000000000 x16: 0000000000000001
[  103.264403] x15: 000899c3a2d9d2e4 x14: 000899bdc3c3a1c8
[  103.269713] x13: 0000000000000000 x12: 0000000000000000
[  103.275024] x11: ffffffc010e30c20 x10: 0000000000000000
[  103.280333] x9 : 0000000000000050 x8 : ffffff8006567d88
[  103.285642] x7 : ffffff8006563b5c x6 : ffffff8006563b44
[  103.290952] x5 : 0000000000000002 x4 : 0000000000000001
[  103.296262] x3 : 0000000000000001 x2 : 0000000000000001
[  103.301572] x1 : 0000000000000000 x0 : 0000000000000011
[  103.306882] Call trace:
[  103.309328]  mt7915_get_phy_mode+0x68/0x120 [mt7915e]
[  103.314378]  mt7915_bss_info_changed+0x198/0x200 [mt7915e]
[  103.319941]  ieee80211_bss_info_change_notify+0x128/0x290 [mac80211]
[  103.326360]  __ieee80211_sta_join_ibss+0x308/0x6c4 [mac80211]
[  103.332171]  ieee80211_sta_create_ibss+0x8c/0x10c [mac80211]
[  103.337895]  ieee80211_ibss_work+0x3dc/0x614 [mac80211]
[  103.343185]  ieee80211_iface_work+0x388/0x3f0 [mac80211]
[  103.348495]  process_one_work+0x288/0x690
[  103.352499]  worker_thread+0x70/0x464
[  103.356157]  kthread+0x144/0x150
[  103.359380]  ret_from_fork+0x10/0x18
[  103.362952] Code: 394008c3 52800220 394000e4 7100007f (39400023)</Note>
    </Notes>
    <CVE>CVE-2021-47540</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings()

In qlcnic_83xx_add_rings(), the indirect function of
ahw-&gt;hw_ops-&gt;alloc_mbx_args will be called to allocate memory for
cmd.req.arg, and there is a dereference of it in qlcnic_83xx_add_rings(),
which could lead to a NULL pointer dereference on failure of the
indirect function like qlcnic_83xx_alloc_mbx_args().

Fix this bug by adding a check of alloc_mbx_args(), this patch
imitates the logic of mbx_cmd()'s failure handling.

This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.

Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.

Builds with CONFIG_QLCNIC=m show no new warnings, and our
static analyzer no longer warns about this code.</Note>
    </Notes>
    <CVE>CVE-2021-47542</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl

When the `rmmod sata_fsl.ko` command is executed in the PPC64 GNU/Linux,
a bug is reported:
 ==================================================================
 BUG: Unable to handle kernel data access on read at 0x80000800805b502c
 Oops: Kernel access of bad area, sig: 11 [#1]
 NIP [c0000000000388a4] .ioread32+0x4/0x20
 LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl]
 Call Trace:
  .free_irq+0x1c/0x4e0 (unreliable)
  .ata_host_stop+0x74/0xd0 [libata]
  .release_nodes+0x330/0x3f0
  .device_release_driver_internal+0x178/0x2c0
  .driver_detach+0x64/0xd0
  .bus_remove_driver+0x70/0xf0
  .driver_unregister+0x38/0x80
  .platform_driver_unregister+0x14/0x30
  .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl]
  .__se_sys_delete_module+0x1ec/0x2d0
  .system_call_exception+0xfc/0x1f0
  system_call_common+0xf8/0x200
 ==================================================================

The triggering of the BUG is shown in the following stack:

driver_detach
  device_release_driver_internal
    __device_release_driver
      drv-&gt;remove(dev) --&gt; platform_drv_remove/platform_remove
        drv-&gt;remove(dev) --&gt; sata_fsl_remove
          iounmap(host_priv-&gt;hcr_base);			&lt;---- unmap
          kfree(host_priv);                             &lt;---- free
      devres_release_all
        release_nodes
          dr-&gt;node.release(dev, dr-&gt;data) --&gt; ata_host_stop
            ap-&gt;ops-&gt;port_stop(ap) --&gt; sata_fsl_port_stop
                ioread32(hcr_base + HCONTROL)           &lt;---- UAF
            host-&gt;ops-&gt;host_stop(host)

The iounmap(host_priv-&gt;hcr_base) and kfree(host_priv) functions should
not be executed in drv-&gt;remove. These functions should be executed in
host_stop after port_stop. Therefore, we move these functions to the
new function sata_fsl_host_stop and bind the new function to host_stop.</Note>
    </Notes>
    <CVE>CVE-2021-47549</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/amdgpu: fix potential memleak

In function amdgpu_get_xgmi_hive, when kobject_init_and_add failed
There is a potential memleak if not call kobject_put.</Note>
    </Notes>
    <CVE>CVE-2021-47550</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/amdkfd: Fix kernel panic when reset failed and been triggered again

In SRIOV configuration, the reset may failed to bring asic back to normal but stop cpsch
already been called, the start_cpsch will not be called since there is no resume in this
case.  When reset been triggered again, driver should avoid to do uninitialization again.</Note>
    </Notes>
    <CVE>CVE-2021-47551</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release()

For avoiding to slow down queue destroy, we don't call
blk_mq_quiesce_queue() in blk_cleanup_queue(), instead of delaying to
cancel dispatch work in blk_release_queue().

However, this way has caused kernel oops[1], reported by Changhui. The log
shows that scsi_device can be freed before running blk_release_queue(),
which is expected too since scsi_device is released after the scsi disk
is closed and the scsi_device is removed.

Fixes the issue by canceling blk-mq dispatch work in both blk_cleanup_queue()
and disk_release():

1) when disk_release() is run, the disk has been closed, and any sync
dispatch activities have been done, so canceling dispatch work is enough to
quiesce filesystem I/O dispatch activity.

2) in blk_cleanup_queue(), we only focus on passthrough request, and
passthrough request is always explicitly allocated &amp; freed by
its caller, so once queue is frozen, all sync dispatch activity
for passthrough request has been done, then it is enough to just cancel
dispatch work for avoiding any dispatch activity.

[1] kernel panic log
[12622.769416] BUG: kernel NULL pointer dereference, address: 0000000000000300
[12622.777186] #PF: supervisor read access in kernel mode
[12622.782918] #PF: error_code(0x0000) - not-present page
[12622.788649] PGD 0 P4D 0
[12622.791474] Oops: 0000 [#1] PREEMPT SMP PTI
[12622.796138] CPU: 10 PID: 744 Comm: kworker/10:1H Kdump: loaded Not tainted 5.15.0+ #1
[12622.804877] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 1.5.4 10/002/2015
[12622.813321] Workqueue: kblockd blk_mq_run_work_fn
[12622.818572] RIP: 0010:sbitmap_get+0x75/0x190
[12622.823336] Code: 85 80 00 00 00 41 8b 57 08 85 d2 0f 84 b1 00 00 00 45 31 e4 48 63 cd 48 8d 1c 49 48 c1 e3 06 49 03 5f 10 4c 8d 6b 40 83 f0 01 &lt;48&gt; 8b 33 44 89 f2 4c 89 ef 0f b6 c8 e8 fa f3 ff ff 83 f8 ff 75 58
[12622.844290] RSP: 0018:ffffb00a446dbd40 EFLAGS: 00010202
[12622.850120] RAX: 0000000000000001 RBX: 0000000000000300 RCX: 0000000000000004
[12622.858082] RDX: 0000000000000006 RSI: 0000000000000082 RDI: ffffa0b7a2dfe030
[12622.866042] RBP: 0000000000000004 R08: 0000000000000001 R09: ffffa0b742721334
[12622.874003] R10: 0000000000000008 R11: 0000000000000008 R12: 0000000000000000
[12622.881964] R13: 0000000000000340 R14: 0000000000000000 R15: ffffa0b7a2dfe030
[12622.889926] FS:  0000000000000000(0000) GS:ffffa0baafb40000(0000) knlGS:0000000000000000
[12622.898956] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[12622.905367] CR2: 0000000000000300 CR3: 0000000641210001 CR4: 00000000001706e0
[12622.913328] Call Trace:
[12622.916055]  &lt;TASK&gt;
[12622.918394]  scsi_mq_get_budget+0x1a/0x110
[12622.922969]  __blk_mq_do_dispatch_sched+0x1d4/0x320
[12622.928404]  ? pick_next_task_fair+0x39/0x390
[12622.933268]  __blk_mq_sched_dispatch_requests+0xf4/0x140
[12622.939194]  blk_mq_sched_dispatch_requests+0x30/0x60
[12622.944829]  __blk_mq_run_hw_queue+0x30/0xa0
[12622.949593]  process_one_work+0x1e8/0x3c0
[12622.954059]  worker_thread+0x50/0x3b0
[12622.958144]  ? rescuer_thread+0x370/0x370
[12622.962616]  kthread+0x158/0x180
[12622.966218]  ? set_kthread_struct+0x40/0x40
[12622.970884]  ret_from_fork+0x22/0x30
[12622.974875]  &lt;/TASK&gt;
[12622.977309] Modules linked in: scsi_debug rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs sunrpc dm_multipath intel_rapl_msr intel_rapl_common dell_wmi_descriptor sb_edac rfkill video x86_pkg_temp_thermal intel_powerclamp dcdbas coretemp kvm_intel kvm mgag200 irqbypass i2c_algo_bit rapl drm_kms_helper ipmi_ssif intel_cstate intel_uncore syscopyarea sysfillrect sysimgblt fb_sys_fops pcspkr cec mei_me lpc_ich mei ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter drm fuse xfs libcrc32c sr_mod cdrom sd_mod t10_pi sg ixgbe ahci libahci crct10dif_pclmul crc32_pclmul crc32c_intel libata megaraid_sas ghash_clmulni_intel tg3 wdat_w
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47552</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sched/scs: Reset task stack state in bringup_cpu()

To hot unplug a CPU, the idle task on that CPU calls a few layers of C
code before finally leaving the kernel. When KASAN is in use, poisoned
shadow is left around for each of the active stack frames, and when
shadow call stacks are in use. When shadow call stacks (SCS) are in use
the task's saved SCS SP is left pointing at an arbitrary point within
the task's shadow call stack.

When a CPU is offlined than onlined back into the kernel, this stale
state can adversely affect execution. Stale KASAN shadow can alias new
stackframes and result in bogus KASAN warnings. A stale SCS SP is
effectively a memory leak, and prevents a portion of the shadow call
stack being used. Across a number of hotplug cycles the idle task's
entire shadow call stack can become unusable.

We previously fixed the KASAN issue in commit:

  e1b77c92981a5222 ("sched/kasan: remove stale KASAN poison after hotplug")

... by removing any stale KASAN stack poison immediately prior to
onlining a CPU.

Subsequently in commit:

  f1a0a376ca0c4ef1 ("sched/core: Initialize the idle task with preemption disabled")

... the refactoring left the KASAN and SCS cleanup in one-time idle
thread initialization code rather than something invoked prior to each
CPU being onlined, breaking both as above.

We fixed SCS (but not KASAN) in commit:

  63acd42c0d4942f7 ("sched/scs: Reset the shadow stack when idle_task_exit")

... but as this runs in the context of the idle task being offlined it's
potentially fragile.

To fix these consistently and more robustly, reset the SCS SP and KASAN
shadow of a CPU's idle task immediately before we online that CPU in
bringup_cpu(). This ensures the idle task always has a consistent state
when it is running, and removes the need to so so when exiting an idle
task.

Whenever any thread is created, dup_task_struct() will give the task a
stack which is free of KASAN shadow, and initialize the task's SCS SP,
so there's no need to specially initialize either for idle thread within
init_idle(), as this was only necessary to handle hotplug cycles.

I've tested this on arm64 with:

* gcc 11.1.0, defconfig +KASAN_INLINE, KASAN_STACK
* clang 12.0.0, defconfig +KASAN_INLINE, KASAN_STACK, SHADOW_CALL_STACK

... offlining and onlining CPUS with:

| while true; do
|   for C in /sys/devices/system/cpu/cpu*/online; do
|     echo 0 &gt; $C;
|     echo 1 &gt; $C;
|   done
| done</Note>
    </Notes>
    <CVE>CVE-2021-47553</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vdpa_sim: avoid putting an uninitialized iova_domain

The system will crash if we put an uninitialized iova_domain, this
could happen when an error occurs before initializing the iova_domain
in vdpasim_create().

BUG: kernel NULL pointer dereference, address: 0000000000000000
...
RIP: 0010:__cpuhp_state_remove_instance+0x96/0x1c0
...
Call Trace:
 &lt;TASK&gt;
 put_iova_domain+0x29/0x220
 vdpasim_free+0xd1/0x120 [vdpa_sim]
 vdpa_release_dev+0x21/0x40 [vdpa]
 device_release+0x33/0x90
 kobject_release+0x63/0x160
 vdpasim_create+0x127/0x2a0 [vdpa_sim]
 vdpasim_net_dev_add+0x7d/0xfe [vdpa_sim_net]
 vdpa_nl_cmd_dev_add_set_doit+0xe1/0x1a0 [vdpa]
 genl_family_rcv_msg_doit+0x112/0x140
 genl_rcv_msg+0xdf/0x1d0
 ...

So we must make sure the iova_domain is already initialized before
put it.

In addition, we may get the following warning in this case:
WARNING: ... drivers/iommu/iova.c:344 iova_cache_put+0x58/0x70

So we must make sure the iova_cache_put() is invoked only if the
iova_cache_get() is already invoked. Let's fix it together.</Note>
    </Notes>
    <CVE>CVE-2021-47554</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: vlan: fix underflow for the real_dev refcnt

Inject error before dev_hold(real_dev) in register_vlan_dev(),
and execute the following testcase:

ip link add dev dummy1 type dummy
ip link add name dummy1.100 link dummy1 type vlan id 100
ip link del dev dummy1

When the dummy netdevice is removed, we will get a WARNING as following:

=======================================================================
refcount_t: decrement hit 0; leaking memory.
WARNING: CPU: 2 PID: 0 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0

and an endless loop of:

=======================================================================
unregister_netdevice: waiting for dummy1 to become free. Usage count = -1073741824

That is because dev_put(real_dev) in vlan_dev_free() be called without
dev_hold(real_dev) in register_vlan_dev(). It makes the refcnt of real_dev
underflow.

Move the dev_hold(real_dev) to vlan_dev_init() which is the call-back of
ndo_init(). That makes dev_hold() and dev_put() for vlan's real_dev
symmetrical.</Note>
    </Notes>
    <CVE>CVE-2021-47555</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ethtool: ioctl: fix potential NULL deref in ethtool_set_coalesce()

ethtool_set_coalesce() now uses both the .get_coalesce() and
.set_coalesce() callbacks. But the check for their availability is
buggy, so changing the coalesce settings on a device where the driver
provides only _one_ of the callbacks results in a NULL pointer
dereference instead of an -EOPNOTSUPP.

Fix the condition so that the availability of both callbacks is
ensured. This also matches the netlink code.

Note that reproducing this requires some effort - it only affects the
legacy ioctl path, and needs a specific combination of driver options:
- have .get_coalesce() and .coalesce_supported but no
 .set_coalesce(), or
- have .set_coalesce() but no .get_coalesce(). Here eg. ethtool doesn't
  cause the crash as it first attempts to call ethtool_get_coalesce()
  and bails out on error.</Note>
    </Notes>
    <CVE>CVE-2021-47556</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/sched: sch_ets: don't peek at classes beyond 'nbands'

when the number of DRR classes decreases, the round-robin active list can
contain elements that have already been freed in ets_qdisc_change(). As a
consequence, it's possible to see a NULL dereference crash, caused by the
attempt to call cl-&gt;qdisc-&gt;ops-&gt;peek(cl-&gt;qdisc) when cl-&gt;qdisc is NULL:

 BUG: kernel NULL pointer dereference, address: 0000000000000018
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] PREEMPT SMP NOPTI
 CPU: 1 PID: 910 Comm: mausezahn Not tainted 5.16.0-rc1+ #475
 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
 RIP: 0010:ets_qdisc_dequeue+0x129/0x2c0 [sch_ets]
 Code: c5 01 41 39 ad e4 02 00 00 0f 87 18 ff ff ff 49 8b 85 c0 02 00 00 49 39 c4 0f 84 ba 00 00 00 49 8b ad c0 02 00 00 48 8b 7d 10 &lt;48&gt; 8b 47 18 48 8b 40 38 0f ae e8 ff d0 48 89 c3 48 85 c0 0f 84 9d
 RSP: 0000:ffffbb36c0b5fdd8 EFLAGS: 00010287
 RAX: ffff956678efed30 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: 0000000000000002 RSI: ffffffff9b938dc9 RDI: 0000000000000000
 RBP: ffff956678efed30 R08: e2f3207fe360129c R09: 0000000000000000
 R10: 0000000000000001 R11: 0000000000000001 R12: ffff956678efeac0
 R13: ffff956678efe800 R14: ffff956611545000 R15: ffff95667ac8f100
 FS:  00007f2aa9120740(0000) GS:ffff95667b800000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000018 CR3: 000000011070c000 CR4: 0000000000350ee0
 Call Trace:
  &lt;TASK&gt;
  qdisc_peek_dequeued+0x29/0x70 [sch_ets]
  tbf_dequeue+0x22/0x260 [sch_tbf]
  __qdisc_run+0x7f/0x630
  net_tx_action+0x290/0x4c0
  __do_softirq+0xee/0x4f8
  irq_exit_rcu+0xf4/0x130
  sysvec_apic_timer_interrupt+0x52/0xc0
  asm_sysvec_apic_timer_interrupt+0x12/0x20
 RIP: 0033:0x7f2aa7fc9ad4
 Code: b9 ff ff 48 8b 54 24 18 48 83 c4 08 48 89 ee 48 89 df 5b 5d e9 ed fc ff ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa &lt;53&gt; 48 83 ec 10 48 8b 05 10 64 33 00 48 8b 00 48 85 c0 0f 85 84 00
 RSP: 002b:00007ffe5d33fab8 EFLAGS: 00000202
 RAX: 0000000000000002 RBX: 0000561f72c31460 RCX: 0000561f72c31720
 RDX: 0000000000000002 RSI: 0000561f72c31722 RDI: 0000561f72c31720
 RBP: 000000000000002a R08: 00007ffe5d33fa40 R09: 0000000000000014
 R10: 0000000000000000 R11: 0000000000000246 R12: 0000561f7187e380
 R13: 0000000000000000 R14: 0000000000000000 R15: 0000561f72c31460
  &lt;/TASK&gt;
 Modules linked in: sch_ets sch_tbf dummy rfkill iTCO_wdt intel_rapl_msr iTCO_vendor_support intel_rapl_common joydev virtio_balloon lpc_ich i2c_i801 i2c_smbus pcspkr ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel ahci libahci ghash_clmulni_intel serio_raw libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod
 CR2: 0000000000000018

Ensuring that 'alist' was never zeroed [1] was not sufficient, we need to
remove from the active list those elements that are no more SP nor DRR.

[1] https://lore.kernel.org/netdev/60d274838bf09777f0371253416e8af71360bc08.1633609148.git.dcaratti@redhat.com/

v3: fix race between ets_qdisc_change() and ets_qdisc_dequeue() delisting
    DRR classes beyond 'nbands' in ets_qdisc_change() with the qdisc lock
    acquired, thanks to Cong Wang.

v2: when a NULL qdisc is found in the DRR active list, try to dequeue skb
    from the next list item.</Note>
    </Notes>
    <CVE>CVE-2021-47557</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: stmmac: Disable Tx queues when reconfiguring the interface

The Tx queues were not disabled in situations where the driver needed to
stop the interface to apply a new configuration. This could result in a
kernel panic when doing any of the 3 following actions:
* reconfiguring the number of queues (ethtool -L)
* reconfiguring the size of the ring buffers (ethtool -G)
* installing/removing an XDP program (ip l set dev ethX xdp)

Prevent the panic by making sure netif_tx_disable is called when stopping
an interface.

Without this patch, the following kernel panic can be observed when doing
any of the actions above:

Unable to handle kernel paging request at virtual address ffff80001238d040
[....]
 Call trace:
  dwmac4_set_addr+0x8/0x10
  dev_hard_start_xmit+0xe4/0x1ac
  sch_direct_xmit+0xe8/0x39c
  __dev_queue_xmit+0x3ec/0xaf0
  dev_queue_xmit+0x14/0x20
[...]
[ end trace 0000000000000002 ]---</Note>
    </Notes>
    <CVE>CVE-2021-47558</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/smc: Fix NULL pointer dereferencing in smc_vlan_by_tcpsk()

Coverity reports a possible NULL dereferencing problem:

in smc_vlan_by_tcpsk():
6. returned_null: netdev_lower_get_next returns NULL (checked 29 out of 30 times).
7. var_assigned: Assigning: ndev = NULL return value from netdev_lower_get_next.
1623                ndev = (struct net_device *)netdev_lower_get_next(ndev, &amp;lower);
CID 1468509 (#1 of 1): Dereference null return value (NULL_RETURNS)
8. dereference: Dereferencing a pointer that might be NULL ndev when calling is_vlan_dev.
1624                if (is_vlan_dev(ndev)) {

Remove the manual implementation and use netdev_walk_all_lower_dev() to
iterate over the lower devices. While on it remove an obsolete function
parameter comment.</Note>
    </Notes>
    <CVE>CVE-2021-47559</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mlxsw: spectrum: Protect driver from buggy firmware

When processing port up/down events generated by the device's firmware,
the driver protects itself from events reported for non-existent local
ports, but not the CPU port (local port 0), which exists, but lacks a
netdev.

This can result in a NULL pointer dereference when calling
netif_carrier_{on,off}().

Fix this by bailing early when processing an event reported for the CPU
port. Problem was only observed when running on top of a buggy emulator.</Note>
    </Notes>
    <CVE>CVE-2021-47560</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: fix vsi-&gt;txq_map sizing

The approach of having XDP queue per CPU regardless of user's setting
exposed a hidden bug that could occur in case when Rx queue count differ
from Tx queue count. Currently vsi-&gt;txq_map's size is equal to the
doubled vsi-&gt;alloc_txq, which is not correct due to the fact that XDP
rings were previously based on the Rx queue count. Below splat can be
seen when ethtool -L is used and XDP rings are configured:

[  682.875339] BUG: kernel NULL pointer dereference, address: 000000000000000f
[  682.883403] #PF: supervisor read access in kernel mode
[  682.889345] #PF: error_code(0x0000) - not-present page
[  682.895289] PGD 0 P4D 0
[  682.898218] Oops: 0000 [#1] PREEMPT SMP PTI
[  682.903055] CPU: 42 PID: 2878 Comm: ethtool Tainted: G           OE     5.15.0-rc5+ #1
[  682.912214] Hardware name: Intel Corp. GRANTLEY/GRANTLEY, BIOS GRRFCRB1.86B.0276.D07.1605190235 05/19/2016
[  682.923380] RIP: 0010:devres_remove+0x44/0x130
[  682.928527] Code: 49 89 f4 55 48 89 fd 4c 89 ff 53 48 83 ec 10 e8 92 b9 49 00 48 8b 9d a8 02 00 00 48 8d 8d a0 02 00 00 49 89 c2 48 39 cb 74 0f &lt;4c&gt; 3b 63 10 74 25 48 8b 5b 08 48 39 cb 75 f1 4c 89 ff 4c 89 d6 e8
[  682.950237] RSP: 0018:ffffc90006a679f0 EFLAGS: 00010002
[  682.956285] RAX: 0000000000000286 RBX: ffffffffffffffff RCX: ffff88908343a370
[  682.964538] RDX: 0000000000000001 RSI: ffffffff81690d60 RDI: 0000000000000000
[  682.972789] RBP: ffff88908343a0d0 R08: 0000000000000000 R09: 0000000000000000
[  682.981040] R10: 0000000000000286 R11: 3fffffffffffffff R12: ffffffff81690d60
[  682.989282] R13: ffffffff81690a00 R14: ffff8890819807a8 R15: ffff88908343a36c
[  682.997535] FS:  00007f08c7bfa740(0000) GS:ffff88a03fd00000(0000) knlGS:0000000000000000
[  683.006910] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  683.013557] CR2: 000000000000000f CR3: 0000001080a66003 CR4: 00000000003706e0
[  683.021819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  683.030075] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  683.038336] Call Trace:
[  683.041167]  devm_kfree+0x33/0x50
[  683.045004]  ice_vsi_free_arrays+0x5e/0xc0 [ice]
[  683.050380]  ice_vsi_rebuild+0x4c8/0x750 [ice]
[  683.055543]  ice_vsi_recfg_qs+0x9a/0x110 [ice]
[  683.060697]  ice_set_channels+0x14f/0x290 [ice]
[  683.065962]  ethnl_set_channels+0x333/0x3f0
[  683.070807]  genl_family_rcv_msg_doit+0xea/0x150
[  683.076152]  genl_rcv_msg+0xde/0x1d0
[  683.080289]  ? channels_prepare_data+0x60/0x60
[  683.085432]  ? genl_get_cmd+0xd0/0xd0
[  683.089667]  netlink_rcv_skb+0x50/0xf0
[  683.094006]  genl_rcv+0x24/0x40
[  683.097638]  netlink_unicast+0x239/0x340
[  683.102177]  netlink_sendmsg+0x22e/0x470
[  683.106717]  sock_sendmsg+0x5e/0x60
[  683.110756]  __sys_sendto+0xee/0x150
[  683.114894]  ? handle_mm_fault+0xd0/0x2a0
[  683.119535]  ? do_user_addr_fault+0x1f3/0x690
[  683.134173]  __x64_sys_sendto+0x25/0x30
[  683.148231]  do_syscall_64+0x3b/0xc0
[  683.161992]  entry_SYSCALL_64_after_hwframe+0x44/0xae

Fix this by taking into account the value that num_possible_cpus()
yields in addition to vsi-&gt;alloc_txq instead of doubling the latter.</Note>
    </Notes>
    <CVE>CVE-2021-47562</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: avoid bpf_prog refcount underflow

Ice driver has the routines for managing XDP resources that are shared
between ndo_bpf op and VSI rebuild flow. The latter takes place for
example when user changes queue count on an interface via ethtool's
set_channels().

There is an issue around the bpf_prog refcounting when VSI is being
rebuilt - since ice_prepare_xdp_rings() is called with vsi-&gt;xdp_prog as
an argument that is used later on by ice_vsi_assign_bpf_prog(), same
bpf_prog pointers are swapped with each other. Then it is also
interpreted as an 'old_prog' which in turn causes us to call
bpf_prog_put on it that will decrement its refcount.

Below splat can be interpreted in a way that due to zero refcount of a
bpf_prog it is wiped out from the system while kernel still tries to
refer to it:

[  481.069429] BUG: unable to handle page fault for address: ffffc9000640f038
[  481.077390] #PF: supervisor read access in kernel mode
[  481.083335] #PF: error_code(0x0000) - not-present page
[  481.089276] PGD 100000067 P4D 100000067 PUD 1001cb067 PMD 106d2b067 PTE 0
[  481.097141] Oops: 0000 [#1] PREEMPT SMP PTI
[  481.101980] CPU: 12 PID: 3339 Comm: sudo Tainted: G           OE     5.15.0-rc5+ #1
[  481.110840] Hardware name: Intel Corp. GRANTLEY/GRANTLEY, BIOS GRRFCRB1.86B.0276.D07.1605190235 05/19/2016
[  481.122021] RIP: 0010:dev_xdp_prog_id+0x25/0x40
[  481.127265] Code: 80 00 00 00 00 0f 1f 44 00 00 89 f6 48 c1 e6 04 48 01 fe 48 8b 86 98 08 00 00 48 85 c0 74 13 48 8b 50 18 31 c0 48 85 d2 74 07 &lt;48&gt; 8b 42 38 8b 40 20 c3 48 8b 96 90 08 00 00 eb e8 66 2e 0f 1f 84
[  481.148991] RSP: 0018:ffffc90007b63868 EFLAGS: 00010286
[  481.155034] RAX: 0000000000000000 RBX: ffff889080824000 RCX: 0000000000000000
[  481.163278] RDX: ffffc9000640f000 RSI: ffff889080824010 RDI: ffff889080824000
[  481.171527] RBP: ffff888107af7d00 R08: 0000000000000000 R09: ffff88810db5f6e0
[  481.179776] R10: 0000000000000000 R11: ffff8890885b9988 R12: ffff88810db5f4bc
[  481.188026] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[  481.196276] FS:  00007f5466d5bec0(0000) GS:ffff88903fb00000(0000) knlGS:0000000000000000
[  481.205633] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  481.212279] CR2: ffffc9000640f038 CR3: 000000014429c006 CR4: 00000000003706e0
[  481.220530] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  481.228771] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  481.237029] Call Trace:
[  481.239856]  rtnl_fill_ifinfo+0x768/0x12e0
[  481.244602]  rtnl_dump_ifinfo+0x525/0x650
[  481.249246]  ? __alloc_skb+0xa5/0x280
[  481.253484]  netlink_dump+0x168/0x3c0
[  481.257725]  netlink_recvmsg+0x21e/0x3e0
[  481.262263]  ____sys_recvmsg+0x87/0x170
[  481.266707]  ? __might_fault+0x20/0x30
[  481.271046]  ? _copy_from_user+0x66/0xa0
[  481.275591]  ? iovec_from_user+0xf6/0x1c0
[  481.280226]  ___sys_recvmsg+0x82/0x100
[  481.284566]  ? sock_sendmsg+0x5e/0x60
[  481.288791]  ? __sys_sendto+0xee/0x150
[  481.293129]  __sys_recvmsg+0x56/0xa0
[  481.297267]  do_syscall_64+0x3b/0xc0
[  481.301395]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  481.307238] RIP: 0033:0x7f5466f39617
[  481.311373] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb bd 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2f 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
[  481.342944] RSP: 002b:00007ffedc7f4308 EFLAGS: 00000246 ORIG_RAX: 000000000000002f
[  481.361783] RAX: ffffffffffffffda RBX: 00007ffedc7f5460 RCX: 00007f5466f39617
[  481.380278] RDX: 0000000000000000 RSI: 00007ffedc7f5360 RDI: 0000000000000003
[  481.398500] RBP: 00007ffedc7f53f0 R08: 0000000000000000 R09: 000055d556f04d50
[  481.416463] R10: 0000000000000077 R11: 0000000000000246 R12: 00007ffedc7f5360
[  481.434131] R13: 00007ffedc7f5350 R14: 00007ffedc7f5344 R15: 0000000000000e98
[  481.451520] Modules linked in: ice
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47563</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: marvell: prestera: fix double free issue on err path

fix error path handling in prestera_bridge_port_join() that
cases prestera driver to crash (see below).

 Trace:
   Internal error: Oops: 96000044 [#1] SMP
   Modules linked in: prestera_pci prestera uio_pdrv_genirq
   CPU: 1 PID: 881 Comm: ip Not tainted 5.15.0 #1
   pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
   pc : prestera_bridge_destroy+0x2c/0xb0 [prestera]
   lr : prestera_bridge_port_join+0x2cc/0x350 [prestera]
   sp : ffff800011a1b0f0
   ...
   x2 : ffff000109ca6c80 x1 : dead000000000100 x0 : dead000000000122
    Call trace:
   prestera_bridge_destroy+0x2c/0xb0 [prestera]
   prestera_bridge_port_join+0x2cc/0x350 [prestera]
   prestera_netdev_port_event.constprop.0+0x3c4/0x450 [prestera]
   prestera_netdev_event_handler+0xf4/0x110 [prestera]
   raw_notifier_call_chain+0x54/0x80
   call_netdevice_notifiers_info+0x54/0xa0
   __netdev_upper_dev_link+0x19c/0x380</Note>
    </Notes>
    <CVE>CVE-2021-47564</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

io_uring: fail cancellation for EXITING tasks

WARNING: CPU: 1 PID: 20 at fs/io_uring.c:6269 io_try_cancel_userdata+0x3c5/0x640 fs/io_uring.c:6269
CPU: 1 PID: 20 Comm: kworker/1:0 Not tainted 5.16.0-rc1-syzkaller #0
Workqueue: events io_fallback_req_func
RIP: 0010:io_try_cancel_userdata+0x3c5/0x640 fs/io_uring.c:6269
Call Trace:
 &lt;TASK&gt;
 io_req_task_link_timeout+0x6b/0x1e0 fs/io_uring.c:6886
 io_fallback_req_func+0xf9/0x1ae fs/io_uring.c:1334
 process_one_work+0x9b2/0x1690 kernel/workqueue.c:2298
 worker_thread+0x658/0x11f0 kernel/workqueue.c:2445
 kthread+0x405/0x4f0 kernel/kthread.c:327
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
 &lt;/TASK&gt;

We need original task's context to do cancellations, so if it's dying
and the callback is executed in a fallback mode, fail the cancellation
attempt.</Note>
    </Notes>
    <CVE>CVE-2021-47569</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In GNOME GdkPixbuf (aka gdk-pixbuf) through 2.42.10, the ANI (Windows animated cursor) decoder encounters heap memory corruption (in ani_load_chunk in io-ani.c) when parsing chunks in a crafted .ani file. A crafted file could allow an attacker to overwrite heap metadata, leading to a denial of service or code execution attack. This occurs in gdk_pixbuf_set_option() in gdk-pixbuf.c.</Note>
    </Notes>
    <CVE>CVE-2022-48622</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/gma500: Fix WARN_ON(lock-&gt;magic != lock) error

psb_gem_unpin() calls dma_resv_lock() but the underlying ww_mutex
gets destroyed by drm_gem_object_release() move the
drm_gem_object_release() call in psb_gem_free_object() to after
the unpin to fix the below warning:

[   79.693962] ------------[ cut here ]------------
[   79.693992] DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)
[   79.694015] WARNING: CPU: 0 PID: 240 at kernel/locking/mutex.c:582 __ww_mutex_lock.constprop.0+0x569/0xfb0
[   79.694052] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer qrtr bnep ath9k ath9k_common ath9k_hw snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel ath3k snd_intel_dspcfg mac80211 snd_intel_sdw_acpi btusb snd_hda_codec btrtl btbcm btintel btmtk bluetooth at24 snd_hda_core snd_hwdep uvcvideo snd_seq libarc4 videobuf2_vmalloc ath videobuf2_memops videobuf2_v4l2 videobuf2_common snd_seq_device videodev acer_wmi intel_powerclamp coretemp mc snd_pcm joydev sparse_keymap ecdh_generic pcspkr wmi_bmof cfg80211 i2c_i801 i2c_smbus snd_timer snd r8169 rfkill lpc_ich soundcore acpi_cpufreq zram rtsx_pci_sdmmc mmc_core serio_raw rtsx_pci gma500_gfx(E) video wmi ip6_tables ip_tables i2c_dev fuse
[   79.694436] CPU: 0 PID: 240 Comm: plymouthd Tainted: G        W   E      6.0.0-rc3+ #490
[   79.694457] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013
[   79.694469] RIP: 0010:__ww_mutex_lock.constprop.0+0x569/0xfb0
[   79.694496] Code: ff 85 c0 0f 84 15 fb ff ff 8b 05 ca 3c 11 01 85 c0 0f 85 07 fb ff ff 48 c7 c6 30 cb 84 aa 48 c7 c7 a3 e1 82 aa e8 ac 29 f8 ff &lt;0f&gt; 0b e9 ed fa ff ff e8 5b 83 8a ff 85 c0 74 10 44 8b 0d 98 3c 11
[   79.694513] RSP: 0018:ffffad1dc048bbe0 EFLAGS: 00010282
[   79.694623] RAX: 0000000000000028 RBX: 0000000000000000 RCX: 0000000000000000
[   79.694636] RDX: 0000000000000001 RSI: ffffffffaa8b0ffc RDI: 00000000ffffffff
[   79.694650] RBP: ffffad1dc048bc80 R08: 0000000000000000 R09: ffffad1dc048ba90
[   79.694662] R10: 0000000000000003 R11: ffffffffaad62fe8 R12: ffff9ff302103138
[   79.694675] R13: ffff9ff306ec8000 R14: ffff9ff307779078 R15: ffff9ff3014c0270
[   79.694690] FS:  00007ff1cccf1740(0000) GS:ffff9ff3bc200000(0000) knlGS:0000000000000000
[   79.694705] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   79.694719] CR2: 0000559ecbcb4420 CR3: 0000000013210000 CR4: 00000000000006f0
[   79.694734] Call Trace:
[   79.694749]  &lt;TASK&gt;
[   79.694761]  ? __schedule+0x47f/0x1670
[   79.694796]  ? psb_gem_unpin+0x27/0x1a0 [gma500_gfx]
[   79.694830]  ? lock_is_held_type+0xe3/0x140
[   79.694864]  ? ww_mutex_lock+0x38/0xa0
[   79.694885]  ? __cond_resched+0x1c/0x30
[   79.694902]  ww_mutex_lock+0x38/0xa0
[   79.694925]  psb_gem_unpin+0x27/0x1a0 [gma500_gfx]
[   79.694964]  psb_gem_unpin+0x199/0x1a0 [gma500_gfx]
[   79.694996]  drm_gem_object_release_handle+0x50/0x60
[   79.695020]  ? drm_gem_object_handle_put_unlocked+0xf0/0xf0
[   79.695042]  idr_for_each+0x4b/0xb0
[   79.695066]  ? _raw_spin_unlock_irqrestore+0x30/0x60
[   79.695095]  drm_gem_release+0x1c/0x30
[   79.695118]  drm_file_free.part.0+0x1ea/0x260
[   79.695150]  drm_release+0x6a/0x120
[   79.695175]  __fput+0x9f/0x260
[   79.695203]  task_work_run+0x59/0xa0
[   79.695227]  do_exit+0x387/0xbe0
[   79.695250]  ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90
[   79.695275]  ? lockdep_hardirqs_on+0x7d/0x100
[   79.695304]  do_group_exit+0x33/0xb0
[   79.695331]  __x64_sys_exit_group+0x14/0x20
[   79.695353]  do_syscall_64+0x58/0x80
[   79.695376]  ? up_read+0x17/0x20
[   79.695401]  ? lock_is_held_type+0xe3/0x140
[   79.695429]  ? asm_exc_page_fault+0x22/0x30
[   79.695450]  ? lockdep_hardirqs_on+0x7d/0x100
[   79.695473]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[   79.695493] RIP: 0033:0x7ff1ccefe3f1
[   79.695516] Code: Unable to access opcode bytes at RIP 0x7ff1ccefe3c7.
[   79.695607] RSP: 002b:00007ffed4413378 EFLAGS: 
---truncated---</Note>
    </Notes>
    <CVE>CVE-2022-48633</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pseries: Fix potential memleak in papr_get_attr()

`buf` is allocated in papr_get_attr(), and krealloc() of `buf`
could fail. We need to free the original `buf` in the case of failure.</Note>
    </Notes>
    <CVE>CVE-2022-48669</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mt76: mt7921e: fix crash in chip reset fail

In case of drv own fail in reset, we may need to run mac_reset several
times. The sequence would trigger system crash as the log below.

Because we do not re-enable/schedule "tx_napi" before disable it again,
the process would keep waiting for state change in napi_diable(). To
avoid the problem and keep status synchronize for each run, goto final
resource handling if drv own failed.

[ 5857.353423] mt7921e 0000:3b:00.0: driver own failed
[ 5858.433427] mt7921e 0000:3b:00.0: Timeout for driver own
[ 5859.633430] mt7921e 0000:3b:00.0: driver own failed
[ 5859.633444] ------------[ cut here ]------------
[ 5859.633446] WARNING: CPU: 6 at kernel/kthread.c:659 kthread_park+0x11d
[ 5859.633717] Workqueue: mt76 mt7921_mac_reset_work [mt7921_common]
[ 5859.633728] RIP: 0010:kthread_park+0x11d/0x150
[ 5859.633736] RSP: 0018:ffff8881b676fc68 EFLAGS: 00010202
......
[ 5859.633766] Call Trace:
[ 5859.633768]  &lt;TASK&gt;
[ 5859.633771]  mt7921e_mac_reset+0x176/0x6f0 [mt7921e]
[ 5859.633778]  mt7921_mac_reset_work+0x184/0x3a0 [mt7921_common]
[ 5859.633785]  ? mt7921_mac_set_timing+0x520/0x520 [mt7921_common]
[ 5859.633794]  ? __kasan_check_read+0x11/0x20
[ 5859.633802]  process_one_work+0x7ee/0x1320
[ 5859.633810]  worker_thread+0x53c/0x1240
[ 5859.633818]  kthread+0x2b8/0x370
[ 5859.633824]  ? process_one_work+0x1320/0x1320
[ 5859.633828]  ? kthread_complete_and_exit+0x30/0x30
[ 5859.633834]  ret_from_fork+0x1f/0x30
[ 5859.633842]  &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2022-48705</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: switch: fix potential memleak in ice_add_adv_recipe()

When ice_add_special_words() fails, the 'rm' is not released, which will
lead to a memory leak. Fix this up by going to 'err_unroll' label.

Compile tested only.</Note>
    </Notes>
    <CVE>CVE-2022-48709</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A heap-buffer-overflow vulnerability was found in LibTIFF, in extractImageSection() at tools/tiffcrop.c:7916 and tools/tiffcrop.c:7801. This flaw allows attackers to cause a denial of service via a crafted tiff file.</Note>
    </Notes>
    <CVE>CVE-2023-3164</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.</Note>
    </Notes>
    <CVE>CVE-2023-45288</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Unlike 32-bit PV guests, HVM guests may switch freely between 64-bit and
other modes.  This in particular means that they may set registers used
to pass 32-bit-mode hypercall arguments to values outside of the range
32-bit code would be able to set them to.

When processing of hypercalls takes a considerable amount of time,
the hypervisor may choose to invoke a hypercall continuation.  Doing so
involves putting (perhaps updated) hypercall arguments in respective
registers.  For guests not running in 64-bit mode this further involves
a certain amount of translation of the values.

Unfortunately internal sanity checking of these translated values
assumes high halves of registers to always be clear when invoking a
hypercall.  When this is found not to be the case, it triggers a
consistency check in the hypervisor and causes a crash.
</Note>
    </Notes>
    <CVE>CVE-2023-46842</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">libexpat through 2.5.0 allows a denial of service (resource consumption) because many full reparsings are required in the case of a large token for which multiple buffer fills are needed.</Note>
    </Notes>
    <CVE>CVE-2023-52425</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: rc: bpf attach/detach requires write permission

Note that bpf attach/detach also requires CAP_NET_ADMIN.</Note>
    </Notes>
    <CVE>CVE-2023-52642</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: fix memleak in iio_device_register_sysfs

When iio_device_register_sysfs_group() fails, we should
free iio_dev_opaque-&gt;chan_attr_group.attrs to prevent
potential memleak.</Note>
    </Notes>
    <CVE>CVE-2023-52643</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

io_uring: drop any code related to SCM_RIGHTS

This is dead code after we dropped support for passing io_uring fds
over SCM_RIGHTS, get rid of it.</Note>
    </Notes>
    <CVE>CVE-2023-52656</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Revert "drm/amd/pm: resolve reboot exception for si oland"

This reverts commit e490d60a2f76bff636c68ce4fe34c1b6c34bbd86.

This causes hangs on SI when DC is enabled and errors on driver
reboot and power off cycles.</Note>
    </Notes>
    <CVE>CVE-2023-52657</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Ensure input to pfn_to_kaddr() is treated as a 64-bit type

On 64-bit platforms, the pfn_to_kaddr() macro requires that the input
value is 64 bits in order to ensure that valid address bits don't get
lost when shifting that input by PAGE_SHIFT to calculate the physical
address to provide a virtual address for.

One such example is in pvalidate_pages() (used by SEV-SNP guests), where
the GFN in the struct used for page-state change requests is a 40-bit
bit-field, so attempts to pass this GFN field directly into
pfn_to_kaddr() ends up causing guest crashes when dealing with addresses
above the 1TB range due to the above.

Fix this issue with SEV-SNP guests, as well as any similar cases that
might cause issues in current/future code, by using an inline function,
instead of a macro, so that the input is implicitly cast to the
expected 64-bit input type prior to performing the shift operation.

While it might be argued that the issue is on the caller side, other
archs/macros have taken similar approaches to deal with instances like
this, such as ARM explicitly casting the input to phys_addr_t:

  e48866647b48 ("ARM: 8396/1: use phys_addr_t in pfn_to_kaddr()")

A C inline function is even better though.

[ mingo: Refined the changelog some more &amp; added __always_inline. ]</Note>
    </Notes>
    <CVE>CVE-2023-52659</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: rkisp1: Fix IRQ handling due to shared interrupts

The driver requests the interrupts as IRQF_SHARED, so the interrupt
handlers can be called at any time. If such a call happens while the ISP
is powered down, the SoC will hang as the driver tries to access the
ISP registers.

This can be reproduced even without the platform sharing the IRQ line:
Enable CONFIG_DEBUG_SHIRQ and unload the driver, and the board will
hang.

Fix this by adding a new field, 'irqs_enabled', which is used to bail
out from the interrupt handler when the ISP is not operational.</Note>
    </Notes>
    <CVE>CVE-2023-52660</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rgb: Fix missing clk_put() in the error handling paths of tegra_dc_rgb_probe()

If clk_get_sys(..., "pll_d2_out0") fails, the clk_get_sys() call must be
undone.

Add the missing clk_put and a new 'put_pll_d_out0' label in the error
handling path, and use it.</Note>
    </Notes>
    <CVE>CVE-2023-52661</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/vmwgfx: fix a memleak in vmw_gmrid_man_get_node

When ida_alloc_max fails, resources allocated before should be freed,
including *res allocated by kmalloc and ttm_resource_init.</Note>
    </Notes>
    <CVE>CVE-2023-52662</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: s390/aes - Fix buffer overread in CTR mode

When processing the last block, the s390 ctr code will always read
a whole block, even if there isn't a whole block of data left.  Fix
this by using the actual length left and copy it into a buffer first
for processing.</Note>
    </Notes>
    <CVE>CVE-2023-52669</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 hang/underflow when transitioning to ODM4:1

[Why]
Under some circumstances, disabling an OPTC and attempting to reclaim
its OPP(s) for a different OPTC could cause a hang/underflow due to OPPs
not being properly disconnected from the disabled OPTC.

[How]
Ensure that all OPPs are unassigned from an OPTC when it gets disabled.</Note>
    </Notes>
    <CVE>CVE-2023-52671</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()

Ensure the value passed to scarlett2_mixer_ctl_put() is between 0 and
SCARLETT2_MIXER_MAX_VALUE so we don't attempt to access outside
scarlett2_mixer_values[].</Note>
    </Notes>
    <CVE>CVE-2023-52674</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Confirm list is non-empty before utilizing list_first_entry in kfd_topology.c

Before using list_first_entry, make sure to check that list is not
empty, if list is empty return -ENODATA.

Fixes the below:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1347 kfd_create_indirect_link_prop() warn: can 'gpu_link' even be NULL?
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1428 kfd_add_peer_prop() warn: can 'iolink1' even be NULL?
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1433 kfd_add_peer_prop() warn: can 'iolink2' even be NULL?</Note>
    </Notes>
    <CVE>CVE-2023-52678</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix double free in of_parse_phandle_with_args_map

In of_parse_phandle_with_args_map() the inner loop that
iterates through the map entries calls of_node_put(new)
to free the reference acquired by the previous iteration
of the inner loop. This assumes that the value of "new" is
NULL on the first iteration of the inner loop.

Make sure that this is true in all iterations of the outer
loop by setting "new" to NULL after its value is assigned to "cur".

Extend the unittest to detect the double free and add an additional
test case that actually triggers this path.</Note>
    </Notes>
    <CVE>CVE-2023-52679</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: scarlett2: Add missing error checks to *_ctl_get()

The *_ctl_get() functions which call scarlett2_update_*() were not
checking the return value. Fix to check the return value and pass to
the caller.</Note>
    </Notes>
    <CVE>CVE-2023-52680</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 to scom_debug_init_one()

kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.
Add a null pointer check, and release 'ent' to avoid memory leaks.</Note>
    </Notes>
    <CVE>CVE-2023-52690</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: scarlett2: Add missing error check to scarlett2_usb_set_config()

scarlett2_usb_set_config() calls scarlett2_usb_get() but was not
checking the result. Return the error if it fails rather than
continuing with an invalid value.</Note>
    </Notes>
    <CVE>CVE-2023-52692</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: tpd12s015: Drop buggy __exit annotation for remove function

With tpd12s015_remove() marked with __exit this function is discarded
when the driver is compiled as a built-in. The result is that when the
driver unbinds there is no cleanup done which results in resource
leakage or worse.</Note>
    </Notes>
    <CVE>CVE-2023-52694</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

sysv: don't call sb_bread() with pointers_lock held

syzbot is reporting sleep in atomic context in SysV filesystem [1], for
sb_bread() is called with rw_spinlock held.

A "write_lock(&amp;pointers_lock) =&gt; read_lock(&amp;pointers_lock) deadlock" bug
and a "sb_bread() with write_lock(&amp;pointers_lock)" bug were introduced by
"Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.

Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the
former bug by moving pointers_lock lock to the callers, but instead
introduced a "sb_bread() with read_lock(&amp;pointers_lock)" bug (which made
this problem easier to hit).

Al Viro suggested that why not to do like get_branch()/get_block()/
find_shared() in Minix filesystem does. And doing like that is almost a
revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch()
 from with find_shared() is called without write_lock(&amp;pointers_lock).</Note>
    </Notes>
    <CVE>CVE-2023-52699</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: openvswitch: fix possible memory leak in ovs_meter_cmd_set()

old_meter needs to be free after it is detached regardless of whether
the new meter is successfully attached.</Note>
    </Notes>
    <CVE>CVE-2023-52702</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

nilfs2: fix underflow in second superblock position calculations

Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second
superblock, underflows when the argument device size is less than 4096
bytes.  Therefore, when using this macro, it is necessary to check in
advance that the device size is not less than a lower limit, or at least
that underflow does not occur.

The current nilfs2 implementation lacks this check, causing out-of-bound
block access when mounting devices smaller than 4096 bytes:

 I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0
 phys_seg 1 prio class 2
 NILFS (loop0): unable to read secondary superblock (blocksize = 1024)

In addition, when trying to resize the filesystem to a size below 4096
bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number
of segments to nilfs_sufile_resize(), corrupting parameters such as the
number of segments in superblocks.  This causes excessive loop iterations
in nilfs_sufile_resize() during a subsequent resize ioctl, causing
semaphore ns_segctor_sem to block for a long time and hang the writer
thread:

 INFO: task segctord:5067 blocked for more than 143 seconds.
      Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0
 "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 task:segctord        state:D stack:23456 pid:5067  ppid:2
 flags:0x00004000
 Call Trace:
  &lt;TASK&gt;
  context_switch kernel/sched/core.c:5293 [inline]
  __schedule+0x1409/0x43f0 kernel/sched/core.c:6606
  schedule+0xc3/0x190 kernel/sched/core.c:6682
  rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190
  nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357
  nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline]
  nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570
  kthread+0x270/0x300 kernel/kthread.c:376
  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
  &lt;/TASK&gt;
 ...
 Call Trace:
  &lt;TASK&gt;
  folio_mark_accessed+0x51c/0xf00 mm/swap.c:515
  __nilfs_get_page_block fs/nilfs2/page.c:42 [inline]
  nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61
  nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121
  nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176
  nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251
  nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline]
  nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline]
  nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777
  nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422
  nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline]
  nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301
  ...

This fixes these issues by inserting appropriate minimum device size
checks or anti-underflow checks, depending on where the macro is used.</Note>
    </Notes>
    <CVE>CVE-2023-52705</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sched/psi: Fix use-after-free in ep_remove_wait_queue()

If a non-root cgroup gets removed when there is a thread that registered
trigger and is polling on a pressure file within the cgroup, the polling
waitqueue gets freed in the following path:

 do_rmdir
   cgroup_rmdir
     kernfs_drain_open_files
       cgroup_file_release
         cgroup_pressure_release
           psi_trigger_destroy

However, the polling thread still has a reference to the pressure file and
will access the freed waitqueue when the file is closed or upon exit:

 fput
   ep_eventpoll_release
     ep_free
       ep_remove_wait_queue
         remove_wait_queue

This results in use-after-free as pasted below.

The fundamental problem here is that cgroup_file_release() (and
consequently waitqueue's lifetime) is not tied to the file's real lifetime.
Using wake_up_pollfree() here might be less than ideal, but it is in line
with the comment at commit 42288cb44c4b ("wait: add wake_up_pollfree()")
since the waitqueue's lifetime is not tied to file's one and can be
considered as another special case. While this would be fixable by somehow
making cgroup_file_release() be tied to the fput(), it would require
sizable refactoring at cgroups or higher layer which might be more
justifiable if we identify more cases like this.

  BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0
  Write of size 4 at addr ffff88810e625328 by task a.out/4404

	CPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38
	Hardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017
	Call Trace:
	&lt;TASK&gt;
	dump_stack_lvl+0x73/0xa0
	print_report+0x16c/0x4e0
	kasan_report+0xc3/0xf0
	kasan_check_range+0x2d2/0x310
	_raw_spin_lock_irqsave+0x60/0xc0
	remove_wait_queue+0x1a/0xa0
	ep_free+0x12c/0x170
	ep_eventpoll_release+0x26/0x30
	__fput+0x202/0x400
	task_work_run+0x11d/0x170
	do_exit+0x495/0x1130
	do_group_exit+0x100/0x100
	get_signal+0xd67/0xde0
	arch_do_signal_or_restart+0x2a/0x2b0
	exit_to_user_mode_prepare+0x94/0x100
	syscall_exit_to_user_mode+0x20/0x40
	do_syscall_64+0x52/0x90
	entry_SYSCALL_64_after_hwframe+0x63/0xcd
	&lt;/TASK&gt;

 Allocated by task 4404:

	kasan_set_track+0x3d/0x60
	__kasan_kmalloc+0x85/0x90
	psi_trigger_create+0x113/0x3e0
	pressure_write+0x146/0x2e0
	cgroup_file_write+0x11c/0x250
	kernfs_fop_write_iter+0x186/0x220
	vfs_write+0x3d8/0x5c0
	ksys_write+0x90/0x110
	do_syscall_64+0x43/0x90
	entry_SYSCALL_64_after_hwframe+0x63/0xcd

 Freed by task 4407:

	kasan_set_track+0x3d/0x60
	kasan_save_free_info+0x27/0x40
	____kasan_slab_free+0x11d/0x170
	slab_free_freelist_hook+0x87/0x150
	__kmem_cache_free+0xcb/0x180
	psi_trigger_destroy+0x2e8/0x310
	cgroup_file_release+0x4f/0xb0
	kernfs_drain_open_files+0x165/0x1f0
	kernfs_drain+0x162/0x1a0
	__kernfs_remove+0x1fb/0x310
	kernfs_remove_by_name_ns+0x95/0xe0
	cgroup_addrm_files+0x67f/0x700
	cgroup_destroy_locked+0x283/0x3c0
	cgroup_rmdir+0x29/0x100
	kernfs_iop_rmdir+0xd1/0x140
	vfs_rmdir+0xfe/0x240
	do_rmdir+0x13d/0x280
	__x64_sys_rmdir+0x2c/0x30
	do_syscall_64+0x43/0x90
	entry_SYSCALL_64_after_hwframe+0x63/0xcd</Note>
    </Notes>
    <CVE>CVE-2023-52707</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mmc: mmc_spi: fix error handling in mmc_spi_probe()

If mmc_add_host() fails, it doesn't need to call mmc_remove_host(),
or it will cause null-ptr-deref, because of deleting a not added
device in mmc_remove_host().

To fix this, goto label 'fail_glue_init', if mmc_add_host() fails,
and change the label 'fail_add_host' to 'fail_gpiod_request'.</Note>
    </Notes>
    <CVE>CVE-2023-52708</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Fix invalid page access after closing deferred I/O devices

When a fbdev with deferred I/O is once opened and closed, the dirty
pages still remain queued in the pageref list, and eventually later
those may be processed in the delayed work.  This may lead to a
corruption of pages, hitting an Oops.

This patch makes sure to cancel the delayed work and clean up the
pageref list at closing the device for addressing the bug.  A part of
the cleanup code is factored out as a new helper function that is
called from the common fb_release().</Note>
    </Notes>
    <CVE>CVE-2023-52731</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/decompressor: specify __decompress() buf len to avoid overflow

Historically calls to __decompress() didn't specify "out_len" parameter
on many architectures including s390, expecting that no writes beyond
uncompressed kernel image are performed. This has changed since commit
2aa14b1ab2c4 ("zstd: import usptream v1.5.2") which includes zstd library
commit 6a7ede3dfccb ("Reduce size of dctx by reutilizing dst buffer
(#2751)"). Now zstd decompression code might store literal buffer in
the unwritten portion of the destination buffer. Since "out_len" is
not set, it is considered to be unlimited and hence free to use for
optimization needs. On s390 this might corrupt initrd or ipl report
which are often placed right after the decompressor buffer. Luckily the
size of uncompressed kernel image is already known to the decompressor,
so to avoid the problem simply specify it in the "out_len" parameter.</Note>
    </Notes>
    <CVE>CVE-2023-52733</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: hda: Do not unset preset when cleaning up codec

Several functions that take part in codec's initialization and removal
are re-used by ASoC codec drivers implementations. Drivers mimic the
behavior of hda_codec_driver_probe/remove() found in
sound/pci/hda/hda_bind.c with their component-&gt;probe/remove() instead.

One of the reasons for that is the expectation of
snd_hda_codec_device_new() to receive a valid pointer to an instance of
struct snd_card. This expectation can be met only once sound card
components probing commences.

As ASoC sound card may be unbound without codec device being actually
removed from the system, unsetting -&gt;preset in
snd_hda_codec_cleanup_for_unbind() interferes with module unload -&gt; load
scenario causing null-ptr-deref. Preset is assigned only once, during
device/driver matching whereas ASoC codec driver's module reloading may
occur several times throughout the lifetime of an audio stack.</Note>
    </Notes>
    <CVE>CVE-2023-52736</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/fence: Fix oops due to non-matching drm_sched init/fini

Currently amdgpu calls drm_sched_fini() from the fence driver sw fini
routine - such function is expected to be called only after the
respective init function - drm_sched_init() - was executed successfully.

Happens that we faced a driver probe failure in the Steam Deck
recently, and the function drm_sched_fini() was called even without
its counter-part had been previously called, causing the following oops:

amdgpu: probe of 0000:04:00.0 failed with error -110
BUG: kernel NULL pointer dereference, address: 0000000000000090
PGD 0 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli #338
Hardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022
RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched]
[...]
Call Trace:
 &lt;TASK&gt;
 amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu]
 amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu]
 amdgpu_driver_release_kms+0x16/0x30 [amdgpu]
 devm_drm_dev_init_release+0x49/0x70
 [...]

To prevent that, check if the drm_sched was properly initialized for a
given ring before calling its fini counter-part.

Notice ideally we'd use sched.ready for that; such field is set as the latest
thing on drm_sched_init(). But amdgpu seems to "override" the meaning of such
field - in the above oops for example, it was a GFX ring causing the crash, and
the sched.ready field was set to true in the ring init routine, regardless of
the state of the DRM scheduler. Hence, we ended-up using sched.ops as per
Christian's suggestion [0], and also removed the no_scheduler check [1].

[0] https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb136@amd.com/
[1] https://lore.kernel.org/amd-gfx/cd0e2994-f85f-d837-609f-7056d5fb7231@amd.com/</Note>
    </Notes>
    <CVE>CVE-2023-52738</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Fix page corruption caused by racy check in __free_pages

When we upgraded our kernel, we started seeing some page corruption like
the following consistently:

  BUG: Bad page state in process ganesha.nfsd  pfn:1304ca
  page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca
  flags: 0x17ffffc0000000()
  raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000
  raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000
  page dumped because: nonzero mapcount
  CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P    B      O      5.10.158-1.nutanix.20221209.el7.x86_64 #1
  Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016
  Call Trace:
   dump_stack+0x74/0x96
   bad_page.cold+0x63/0x94
   check_new_page_bad+0x6d/0x80
   rmqueue+0x46e/0x970
   get_page_from_freelist+0xcb/0x3f0
   ? _cond_resched+0x19/0x40
   __alloc_pages_nodemask+0x164/0x300
   alloc_pages_current+0x87/0xf0
   skb_page_frag_refill+0x84/0x110
   ...

Sometimes, it would also show up as corruption in the free list pointer
and cause crashes.

After bisecting the issue, we found the issue started from commit
e320d3012d25 ("mm/page_alloc.c: fix freeing non-compound pages"):

	if (put_page_testzero(page))
		free_the_page(page, order);
	else if (!PageHead(page))
		while (order-- &gt; 0)
			free_the_page(page + (1 &lt;&lt; order), order);

So the problem is the check PageHead is racy because at this point we
already dropped our reference to the page.  So even if we came in with
compound page, the page can already be freed and PageHead can return
false and we will end up freeing all the tail pages causing double free.</Note>
    </Notes>
    <CVE>CVE-2023-52739</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/interrupt: Fix interrupt exit race with security mitigation switch

The RFI and STF security mitigation options can flip the
interrupt_exit_not_reentrant static branch condition concurrently with
the interrupt exit code which tests that branch.

Interrupt exit tests this condition to set MSR[EE|RI] for exit, then
again in the case a soft-masked interrupt is found pending, to recover
the MSR so the interrupt can be replayed before attempting to exit
again. If the condition changes between these two tests, the MSR and irq
soft-mask state will become corrupted, leading to warnings and possible
crashes. For example, if the branch is initially true then false,
MSR[EE] will be 0 but PACA_IRQ_HARD_DIS clear and EE may not get
enabled, leading to warnings in irq_64.c.</Note>
    </Notes>
    <CVE>CVE-2023-52740</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: Do not use WQ_MEM_RECLAIM flag for workqueue

When both ice and the irdma driver are loaded, a warning in
check_flush_dependency is being triggered. This is due to ice driver
workqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma one
is not.

According to kernel documentation, this flag should be set if the
workqueue will be involved in the kernel's memory reclamation flow.
Since it is not, there is no need for the ice driver's WQ to have this
flag set so remove it.

Example trace:

[  +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0
[  +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0
[  +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha
in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel
_rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1
0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_
core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs
ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter
acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba
ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse
[  +0.000161]  [last unloaded: bonding]
[  +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S                 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1
[  +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020
[  +0.000003] Workqueue: ice ice_service_task [ice]
[  +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0
[  +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08
9f e8 bb d3 07 01 &lt;0f&gt; 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06
[  +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282
[  +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000
[  +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80
[  +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112
[  +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000
[  +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400
[  +0.000004] FS:  0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000
[  +0.000003] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0
[  +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  +0.000002] PKRU: 55555554
[  +0.000003] Call Trace:
[  +0.000002]  &lt;TASK&gt;
[  +0.000003]  __flush_workqueue+0x203/0x840
[  +0.000006]  ? mutex_unlock+0x84/0xd0
[  +0.000008]  ? __pfx_mutex_unlock+0x10/0x10
[  +0.000004]  ? __pfx___flush_workqueue+0x10/0x10
[  +0.000006]  ? mutex_lock+0xa3/0xf0
[  +0.000005]  ib_cache_cleanup_one+0x39/0x190 [ib_core]
[  +0.000174]  __ib_unregister_device+0x84/0xf0 [ib_core]
[  +0.000094]  ib_unregister_device+0x25/0x30 [ib_core]
[  +0.000093]  irdma_ib_unregister_device+0x97/0xc0 [irdma]
[  +0.000064]  ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma]
[  +0.000059]  ? up_write+0x5c/0x90
[  +0.000005]  irdma_remove+0x36/0x90 [irdma]
[  +0.000062]  auxiliary_bus_remove+0x32/0x50
[  +0.000007]  device_r
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-52743</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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/irdma: Fix potential NULL-ptr-dereference

in_dev_get() can return NULL which will cause a failure once idev is
dereferenced in in_dev_for_each_ifa_rtnl(). This patch adds a
check for NULL value in idev beforehand.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2023-52744</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 legacy IPoIB due to wrong number of queues

The cited commit creates child PKEY interfaces over netlink will
multiple tx and rx queues, but some devices doesn't support more than 1
tx and 1 rx queues. This causes to a crash when traffic is sent over the
PKEY interface due to the parent having a single queue but the child
having multiple queues.

This patch fixes the number of queues to 1 for legacy IPoIB at the
earliest possible point in time.

BUG: kernel NULL pointer dereference, address: 000000000000036b
PGD 0 P4D 0
Oops: 0000 [#1] SMP
CPU: 4 PID: 209665 Comm: python3 Not tainted 6.1.0_for_upstream_min_debug_2022_12_12_17_02 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:kmem_cache_alloc+0xcb/0x450
Code: ce 7e 49 8b 50 08 49 83 78 10 00 4d 8b 28 0f 84 cb 02 00 00 4d 85 ed 0f 84 c2 02 00 00 41 8b 44 24 28 48 8d 4a
01 49 8b 3c 24 &lt;49&gt; 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b8 41 8b
RSP: 0018:ffff88822acbbab8 EFLAGS: 00010202
RAX: 0000000000000070 RBX: ffff8881c28e3e00 RCX: 00000000064f8dae
RDX: 00000000064f8dad RSI: 0000000000000a20 RDI: 0000000000030d00
RBP: 0000000000000a20 R08: ffff8882f5d30d00 R09: ffff888104032f40
R10: ffff88810fade828 R11: 736f6d6570736575 R12: ffff88810081c000
R13: 00000000000002fb R14: ffffffff817fc865 R15: 0000000000000000
FS:  00007f9324ff9700(0000) GS:ffff8882f5d00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000036b CR3: 00000001125af004 CR4: 0000000000370ea0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 skb_clone+0x55/0xd0
 ip6_finish_output2+0x3fe/0x690
 ip6_finish_output+0xfa/0x310
 ip6_send_skb+0x1e/0x60
 udp_v6_send_skb+0x1e5/0x420
 udpv6_sendmsg+0xb3c/0xe60
 ? ip_mc_finish_output+0x180/0x180
 ? __switch_to_asm+0x3a/0x60
 ? __switch_to_asm+0x34/0x60
 sock_sendmsg+0x33/0x40
 __sys_sendto+0x103/0x160
 ? _copy_to_user+0x21/0x30
 ? kvm_clock_get_cycles+0xd/0x10
 ? ktime_get_ts64+0x49/0xe0
 __x64_sys_sendto+0x25/0x30
 do_syscall_64+0x3d/0x90
 entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7f9374f1ed14
Code: 42 41 f8 ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b
7c 24 08 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 68 41 f8 ff 48 8b
RSP: 002b:00007f9324ff7bd0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00007f9324ff7cc8 RCX: 00007f9374f1ed14
RDX: 00000000000002fb RSI: 00007f93000052f0 RDI: 0000000000000030
RBP: 0000000000000000 R08: 00007f9324ff7d40 R09: 000000000000001c
R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
R13: 000000012a05f200 R14: 0000000000000001 R15: 00007f9374d57bdc
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2023-52745</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr()

  int type = nla_type(nla);

  if (type &gt; XFRMA_MAX) {
            return -EOPNOTSUPP;
  }

@type is then used as an array index and can be used
as a Spectre v1 gadget.

  if (nla_len(nla) &lt; compat_policy[type].len) {

array_index_nospec() can be used to prevent leaking
content of kernel memory to malicious users.</Note>
    </Notes>
    <CVE>CVE-2023-52746</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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

i3c: master: mipi-i3c-hci: Fix a kernel panic for accessing DAT_data.

The `i3c_master_bus_init` function may attach the I2C devices before the
I3C bus initialization. In this flow, the DAT `alloc_entry`` will be used
before the DAT `init`. Additionally, if the `i3c_master_bus_init` fails,
the DAT `cleanup` will execute before the device is detached, which will
execue DAT `free_entry` function. The above scenario can cause the driver
to use DAT_data when it is NULL.</Note>
    </Notes>
    <CVE>CVE-2023-52763</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i3c: mipi-i3c-hci: Fix out of bounds access in hci_dma_irq_handler

Do not loop over ring headers in hci_dma_irq_handler() that are not
allocated and enabled in hci_dma_init(). Otherwise out of bounds access
will occur from rings-&gt;headers[i] access when i &gt;= number of allocated
ring headers.</Note>
    </Notes>
    <CVE>CVE-2023-52766</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 a NULL pointer dereference in amdgpu_dm_i2c_xfer()

When ddc_service_construct() is called, it explicitly checks both the
link type and whether there is something on the link which will
dictate whether the pin is marked as hw_supported.

If the pin isn't set or the link is not set (such as from
unloading/reloading amdgpu in an IGT test) then fail the
amdgpu_dm_i2c_xfer() call.</Note>
    </Notes>
    <CVE>CVE-2023-52773</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: fix gtk offload status event locking

The ath11k active pdevs are protected by RCU but the gtk offload status
event handling code calling ath11k_mac_get_arvif_by_vdev_id() was not
marked as a read-side critical section.

Mark the code in question as an RCU read-side critical section to avoid
any potential use-after-free issues.

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

i915/perf: Fix NULL deref bugs with drm_dbg() calls

When i915 perf interface is not available dereferencing it will lead to
NULL dereferences.

As returning -ENOTSUPP is pretty clear return when perf interface is not
available.

[tursulin: added stable tag]
(cherry picked from commit 36f27350ff745bd228ab04d7845dfbffc177a889)</Note>
    </Notes>
    <CVE>CVE-2023-52788</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: vcc: Add check for kstrdup() in vcc_probe()

Add check for the return value of kstrdup() and return the error, if it
fails in order to avoid NULL pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2023-52789</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: Run atomic i2c xfer when !preemptible

Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is
disabled. However, non-atomic i2c transfers require preemption (e.g. in
wait_for_completion() while waiting for the DMA).

panic() calls preempt_disable_notrace() before calling
emergency_restart(). Therefore, if an i2c device is used for the
restart, the xfer should be atomic. This avoids warnings like:

[   12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0
[   12.676926] Voluntary context switch within RCU read-side critical section!
...
[   12.742376]  schedule_timeout from wait_for_completion_timeout+0x90/0x114
[   12.749179]  wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70
...
[   12.994527]  atomic_notifier_call_chain from machine_restart+0x34/0x58
[   13.001050]  machine_restart from panic+0x2a8/0x32c

Use !preemptible() instead, which is basically the same check as
pre-v5.2.</Note>
    </Notes>
    <CVE>CVE-2023-52791</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

vhost-vdpa: fix use after free in vhost_vdpa_probe()

The put_device() calls vhost_vdpa_release_dev() which calls
ida_simple_remove() and frees "v".  So this call to
ida_simple_remove() is a use after free and a double free.</Note>
    </Notes>
    <CVE>CVE-2023-52795</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: fix dfs radar event locking

The ath11k active pdevs are protected by RCU but the DFS radar event
handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a
read-side critical section.

Mark the code in question as an RCU read-side critical section to avoid
any potential use-after-free issues.

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

jfs: fix array-index-out-of-bounds in dbFindLeaf

Currently while searching for dmtree_t for sufficient free blocks there
is an array out of bounds while getting element in tp-&gt;dm_stree. To add
the required check for out of bound we first need to determine the type
of dmtree. Thus added an extra parameter to dbFindLeaf so that the type
of tree can be determined and the required check can be applied.</Note>
    </Notes>
    <CVE>CVE-2023-52799</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: fix htt pktlog locking

The ath11k active pdevs are protected by RCU but the htt pktlog handling
code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a
read-side critical section.

Mark the code in question as an RCU read-side critical section to avoid
any potential use-after-free issues.

Compile tested only.</Note>
    </Notes>
    <CVE>CVE-2023-52800</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/jfs: Add validity check for db_maxag and db_agpref

Both db_maxag and db_agpref are used as the index of the
db_agfree array, but there is currently no validity check for
db_maxag and db_agpref, which can lead to errors.

The following is related bug reported by Syzbot:

UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20
index 7936 is out of range for type 'atomic_t[128]'

Add checking that the values of db_maxag and db_agpref are valid
indexes for the db_agfree array.</Note>
    </Notes>
    <CVE>CVE-2023-52804</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

jfs: fix array-index-out-of-bounds in diAlloc

Currently there is not check against the agno of the iag while
allocating new inodes to avoid fragmentation problem. Added the check
which is required.</Note>
    </Notes>
    <CVE>CVE-2023-52805</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: hda: Fix possible null-ptr-deref when assigning a stream

While AudioDSP drivers assign streams exclusively of HOST or LINK type,
nothing blocks a user to attempt to assign a COUPLED stream. As
supplied substream instance may be a stub, what is the case when
code-loading, such scenario ends with null-ptr-deref.</Note>
    </Notes>
    <CVE>CVE-2023-52806</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: hns3: fix out-of-bounds access may occur when coalesce info is read via debugfs

The hns3 driver define an array of string to show the coalesce
info, but if the kernel adds a new mode or a new state,
out-of-bounds access may occur when coalesce info is read via
debugfs, this patch fix the problem.</Note>
    </Notes>
    <CVE>CVE-2023-52807</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/jfs: Add check for negative db_l2nbperpage

l2nbperpage is log2(number of blks per page), and the minimum legal
value should be 0, not negative.

In the case of l2nbperpage being negative, an error will occur
when subsequently used as shift exponent.

Syzbot reported this bug:

UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12
shift exponent -16777216 is negative</Note>
    </Notes>
    <CVE>CVE-2023-52810</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ibmvfc: Remove BUG_ON in the case of an empty event pool

In practice the driver should never send more commands than are allocated
to a queue's event pool. In the unlikely event that this happens, the code
asserts a BUG_ON, and in the case that the kernel is not configured to
crash on panic returns a junk event pointer from the empty event list
causing things to spiral from there. This BUG_ON is a historical artifact
of the ibmvfc driver first being upstreamed, and it is well known now that
the use of BUG_ON is bad practice except in the most unrecoverable
scenario. There is nothing about this scenario that prevents the driver
from recovering and carrying on.

Remove the BUG_ON in question from ibmvfc_get_event() and return a NULL
pointer in the case of an empty event pool. Update all call sites to
ibmvfc_get_event() to check for a NULL pointer and perfrom the appropriate
failure or recovery action.</Note>
    </Notes>
    <CVE>CVE-2023-52811</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential null pointer derefernce

The amdgpu_ras_get_context may return NULL if device
not support ras feature, so add check before using.</Note>
    </Notes>
    <CVE>CVE-2023-52814</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/vkms: fix a possible null pointer dereference

In amdgpu_vkms_conn_get_modes(), the return value of drm_cvt_mode()
is assigned to mode, which will lead to a NULL pointer dereference
on failure of drm_cvt_mode(). Add a check to avoid null pointer
dereference.</Note>
    </Notes>
    <CVE>CVE-2023-52815</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Fix shift out-of-bounds issue

[  567.613292] shift exponent 255 is too large for 64-bit type 'long unsigned int'
[  567.614498] CPU: 5 PID: 238 Comm: kworker/5:1 Tainted: G           OE      6.2.0-34-generic #34~22.04.1-Ubuntu
[  567.614502] Hardware name: AMD Splinter/Splinter-RPL, BIOS WS43927N_871 09/25/2023
[  567.614504] Workqueue: events send_exception_work_handler [amdgpu]
[  567.614748] Call Trace:
[  567.614750]  &lt;TASK&gt;
[  567.614753]  dump_stack_lvl+0x48/0x70
[  567.614761]  dump_stack+0x10/0x20
[  567.614763]  __ubsan_handle_shift_out_of_bounds+0x156/0x310
[  567.614769]  ? srso_alias_return_thunk+0x5/0x7f
[  567.614773]  ? update_sd_lb_stats.constprop.0+0xf2/0x3c0
[  567.614780]  svm_range_split_by_granularity.cold+0x2b/0x34 [amdgpu]
[  567.615047]  ? srso_alias_return_thunk+0x5/0x7f
[  567.615052]  svm_migrate_to_ram+0x185/0x4d0 [amdgpu]
[  567.615286]  do_swap_page+0x7b6/0xa30
[  567.615291]  ? srso_alias_return_thunk+0x5/0x7f
[  567.615294]  ? __free_pages+0x119/0x130
[  567.615299]  handle_pte_fault+0x227/0x280
[  567.615303]  __handle_mm_fault+0x3c0/0x720
[  567.615311]  handle_mm_fault+0x119/0x330
[  567.615314]  ? lock_mm_and_find_vma+0x44/0x250
[  567.615318]  do_user_addr_fault+0x1a9/0x640
[  567.615323]  exc_page_fault+0x81/0x1b0
[  567.615328]  asm_exc_page_fault+0x27/0x30
[  567.615332] RIP: 0010:__get_user_8+0x1c/0x30</Note>
    </Notes>
    <CVE>CVE-2023-52816</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Fix a race condition of vram buffer unref in svm code

prange-&gt;svm_bo unref can happen in both mmu callback and a callback after
migrate to system ram. Both are async call in different tasks. Sync svm_bo
unref operation to avoid random "use-after-free".</Note>
    </Notes>
    <CVE>CVE-2023-52825</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/panel-tpo-tpg110: fix a possible null pointer dereference

In tpg110_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-52826</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: btusb: Add date-&gt;evt_skb is NULL check

fix crash because of null pointers

[ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8
[ 6104.969667] #PF: supervisor read access in kernel mode
[ 6104.969668] #PF: error_code(0x0000) - not-present page
[ 6104.969670] PGD 0 P4D 0
[ 6104.969673] Oops: 0000 [#1] SMP NOPTI
[ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb]
[ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246
[ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006
[ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000
[ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001
[ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0
[ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90
[ 6104.969697] FS:  00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000
[ 6104.969699] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0
[ 6104.969701] PKRU: 55555554
[ 6104.969702] Call Trace:
[ 6104.969708]  btusb_mtk_shutdown+0x44/0x80 [btusb]
[ 6104.969732]  hci_dev_do_close+0x470/0x5c0 [bluetooth]
[ 6104.969748]  hci_rfkill_set_block+0x56/0xa0 [bluetooth]
[ 6104.969753]  rfkill_set_block+0x92/0x160
[ 6104.969755]  rfkill_fop_write+0x136/0x1e0
[ 6104.969759]  __vfs_write+0x18/0x40
[ 6104.969761]  vfs_write+0xdf/0x1c0
[ 6104.969763]  ksys_write+0xb1/0xe0
[ 6104.969765]  __x64_sys_write+0x1a/0x20
[ 6104.969769]  do_syscall_64+0x51/0x180
[ 6104.969771]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 6104.969773] RIP: 0033:0x7f5a21f18fef
[ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
[ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef
[ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012
[ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017
[ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002
[ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0</Note>
    </Notes>
    <CVE>CVE-2023-52833</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: imsttfb: fix a resource leak in probe

I've re-written the error handling but the bug is that if init_imstt()
fails we need to call iounmap(par-&gt;cmap_regs).</Note>
    </Notes>
    <CVE>CVE-2023-52838</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()

The put_device() calls rmi_release_function() which frees "fn" so the
dereference on the next line "fn-&gt;num_of_irqs" is a use after free.
Move the put_device() to the end to fix this.</Note>
    </Notes>
    <CVE>CVE-2023-52840</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: vidtv: mux: Add check and kfree for kstrdup

Add check for the return value of kstrdup() and return the error
if it fails in order to avoid NULL pointer dereference.
Moreover, use kfree() in the later error handling in order to avoid
memory leak.</Note>
    </Notes>
    <CVE>CVE-2023-52841</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: vidtv: psi: Add check for kstrdup

Add check for the return value of kstrdup() and return the error
if it fails in order to avoid NULL pointer dereference.</Note>
    </Notes>
    <CVE>CVE-2023-52844</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: bttv: fix use after free error due to btv-&gt;timeout timer

There may be some a race condition between timer function
bttv_irq_timeout and bttv_remove. The timer is setup in
probe and there is no timer_delete operation in remove
function. When it hit kfree btv, the function might still be
invoked, which will cause use after free bug.

This bug is found by static analysis, it may be false positive.

Fix it by adding del_timer_sync invoking to the remove function.

cpu0                cpu1
                  bttv_probe
                    -&gt;timer_setup
                      -&gt;bttv_set_dma
                        -&gt;mod_timer;
bttv_remove
  -&gt;kfree(btv);
                  -&gt;bttv_irq_timeout
                    -&gt;USE btv</Note>
    </Notes>
    <CVE>CVE-2023-52847</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 init stage error handling to avoid double free of same QP and UAF

In the unlikely event that workqueue allocation fails and returns NULL in
mlx5_mkey_cache_init(), delete the call to
mlx5r_umr_resource_cleanup() (which frees the QP) in
mlx5_ib_stage_post_ib_reg_umr_init().  This will avoid attempted double
free of the same QP when __mlx5_ib_add() does its cleanup.

Resolves a splat:

   Syzkaller reported a UAF in ib_destroy_qp_user

   workqueue: Failed to create a rescuer kthread for wq "mkey_cache": -EINTR
   infiniband mlx5_0: mlx5_mkey_cache_init:981:(pid 1642):
   failed to create work queue
   infiniband mlx5_0: mlx5_ib_stage_post_ib_reg_umr_init:4075:(pid 1642):
   mr cache init failed -12
   ==================================================================
   BUG: KASAN: slab-use-after-free in ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2073)
   Read of size 8 at addr ffff88810da310a8 by task repro_upstream/1642

   Call Trace:
   &lt;TASK&gt;
   kasan_report (mm/kasan/report.c:590)
   ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2073)
   mlx5r_umr_resource_cleanup (drivers/infiniband/hw/mlx5/umr.c:198)
   __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4178)
   mlx5r_probe (drivers/infiniband/hw/mlx5/main.c:4402)
   ...
   &lt;/TASK&gt;

   Allocated by task 1642:
   __kmalloc (./include/linux/kasan.h:198 mm/slab_common.c:1026
   mm/slab_common.c:1039)
   create_qp (./include/linux/slab.h:603 ./include/linux/slab.h:720
   ./include/rdma/ib_verbs.h:2795 drivers/infiniband/core/verbs.c:1209)
   ib_create_qp_kernel (drivers/infiniband/core/verbs.c:1347)
   mlx5r_umr_resource_init (drivers/infiniband/hw/mlx5/umr.c:164)
   mlx5_ib_stage_post_ib_reg_umr_init (drivers/infiniband/hw/mlx5/main.c:4070)
   __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4168)
   mlx5r_probe (drivers/infiniband/hw/mlx5/main.c:4402)
   ...

   Freed by task 1642:
   __kmem_cache_free (mm/slub.c:1826 mm/slub.c:3809 mm/slub.c:3822)
   ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2112)
   mlx5r_umr_resource_cleanup (drivers/infiniband/hw/mlx5/umr.c:198)
   mlx5_ib_stage_post_ib_reg_umr_init (drivers/infiniband/hw/mlx5/main.c:4076
   drivers/infiniband/hw/mlx5/main.c:4065)
   __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4168)
   mlx5r_probe (drivers/infiniband/hw/mlx5/main.c:4402)
   ...</Note>
    </Notes>
    <CVE>CVE-2023-52851</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: cp2112: Fix duplicate workqueue initialization

Previously the cp2112 driver called INIT_DELAYED_WORK within
cp2112_gpio_irq_startup, resulting in duplicate initilizations of the
workqueue on subsequent IRQ startups following an initial request. This
resulted in a warning in set_work_data in workqueue.c, as well as a rare
NULL dereference within process_one_work in workqueue.c.

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

padata: Fix refcnt handling in padata_free_shell()

In a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead
to system UAF (Use-After-Free) issues. Due to the lengthy analysis of
the pcrypt_aead01 function call, I'll describe the problem scenario
using a simplified model:

Suppose there's a user of padata named `user_function` that adheres to
the padata requirement of calling `padata_free_shell` after `serial()`
has been invoked, as demonstrated in the following code:

```c
struct request {
    struct padata_priv padata;
    struct completion *done;
};

void parallel(struct padata_priv *padata) {
    do_something();
}

void serial(struct padata_priv *padata) {
    struct request *request = container_of(padata,
    				struct request,
				padata);
    complete(request-&gt;done);
}

void user_function() {
    DECLARE_COMPLETION(done)
    padata-&gt;parallel = parallel;
    padata-&gt;serial = serial;
    padata_do_parallel();
    wait_for_completion(&amp;done);
    padata_free_shell();
}
```

In the corresponding padata.c file, there's the following code:

```c
static void padata_serial_worker(struct work_struct *serial_work) {
    ...
    cnt = 0;

    while (!list_empty(&amp;local_list)) {
        ...
        padata-&gt;serial(padata);
        cnt++;
    }

    local_bh_enable();

    if (refcount_sub_and_test(cnt, &amp;pd-&gt;refcnt))
        padata_free_pd(pd);
}
```

Because of the high system load and the accumulation of unexecuted
softirq at this moment, `local_bh_enable()` in padata takes longer
to execute than usual. Subsequently, when accessing `pd-&gt;refcnt`,
`pd` has already been released by `padata_free_shell()`, resulting
in a UAF issue with `pd-&gt;refcnt`.

The fix is straightforward: add `refcount_dec_and_test` before calling
`padata_free_pd` in `padata_free_shell`.</Note>
    </Notes>
    <CVE>CVE-2023-52854</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: lt8912b: Fix crash on bridge detach

The lt8912b driver, in its bridge detach function, calls
drm_connector_unregister() and drm_connector_cleanup().

drm_connector_unregister() should be called only for connectors
explicitly registered with drm_connector_register(), which is not the
case in lt8912b.

The driver's drm_connector_funcs.destroy hook is set to
drm_connector_cleanup().

Thus the driver should not call either drm_connector_unregister() nor
drm_connector_cleanup() in its lt8912_bridge_detach(), as they cause a
crash on bridge detach:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Mem abort info:
  ESR = 0x0000000096000006
  EC = 0x25: DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
  FSC = 0x06: level 2 translation fault
Data abort info:
  ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
  CM = 0, WnR = 0, TnD = 0, TagAccess = 0
  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=00000000858f3000
[0000000000000000] pgd=0800000085918003, p4d=0800000085918003, pud=0800000085431003, pmd=0000000000000000
Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP
Modules linked in: tidss(-) display_connector lontium_lt8912b tc358768 panel_lvds panel_simple drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks
CPU: 3 PID: 462 Comm: rmmod Tainted: G        W          6.5.0-rc2+ #2
Hardware name: Toradex Verdin AM62 on Verdin Development Board (DT)
pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_connector_cleanup+0x78/0x2d4 [drm]
lr : lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b]
sp : ffff800082ed3a90
x29: ffff800082ed3a90 x28: ffff0000040c1940 x27: 0000000000000000
x26: 0000000000000000 x25: dead000000000122 x24: dead000000000122
x23: dead000000000100 x22: ffff000003fb6388 x21: 0000000000000000
x20: 0000000000000000 x19: ffff000003fb6260 x18: fffffffffffe56e8
x17: 0000000000000000 x16: 0010000000000000 x15: 0000000000000038
x14: 0000000000000000 x13: ffff800081914b48 x12: 000000000000040e
x11: 000000000000015a x10: ffff80008196ebb8 x9 : ffff800081914b48
x8 : 00000000ffffefff x7 : ffff0000040c1940 x6 : ffff80007aa649d0
x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffff80008159e008
x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
 drm_connector_cleanup+0x78/0x2d4 [drm]
 lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b]
 drm_bridge_detach+0x44/0x84 [drm]
 drm_encoder_cleanup+0x40/0xb8 [drm]
 drmm_encoder_alloc_release+0x1c/0x30 [drm]
 drm_managed_release+0xac/0x148 [drm]
 drm_dev_put.part.0+0x88/0xb8 [drm]
 devm_drm_dev_init_release+0x14/0x24 [drm]
 devm_action_release+0x14/0x20
 release_nodes+0x5c/0x90
 devres_release_all+0x8c/0xe0
 device_unbind_cleanup+0x18/0x68
 device_release_driver_internal+0x208/0x23c
 driver_detach+0x4c/0x94
 bus_remove_driver+0x70/0xf4
 driver_unregister+0x30/0x60
 platform_driver_unregister+0x14/0x20
 tidss_platform_driver_exit+0x18/0xb2c [tidss]
 __arm64_sys_delete_module+0x1a0/0x2b4
 invoke_syscall+0x48/0x110
 el0_svc_common.constprop.0+0x60/0x10c
 do_el0_svc_compat+0x1c/0x40
 el0_svc_compat+0x40/0xac
 el0t_32_sync_handler+0xb0/0x138
 el0t_32_sync+0x194/0x198
Code: 9104a276 f2fbd5b7 aa0203e1 91008af8 (f85c0420)</Note>
    </Notes>
    <CVE>CVE-2023-52856</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-mt7629: 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-52858</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drivers/perf: hisi: use cpuhp_state_remove_instance_nocalls() for hisi_hns3_pmu uninit process

When tearing down a 'hisi_hns3' PMU, we mistakenly run the CPU hotplug
callbacks after the device has been unregistered, leading to fireworks
when we try to execute empty function callbacks within the driver:

  | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
  | CPU: 0 PID: 15 Comm: cpuhp/0 Tainted: G        W  O      5.12.0-rc4+ #1
  | Hardware name:  , BIOS KpxxxFPGA 1P B600 V143 04/22/2021
  | pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
  | pc : perf_pmu_migrate_context+0x98/0x38c
  | lr : perf_pmu_migrate_context+0x94/0x38c
  |
  | Call trace:
  |  perf_pmu_migrate_context+0x98/0x38c
  |  hisi_hns3_pmu_offline_cpu+0x104/0x12c [hisi_hns3_pmu]

Use cpuhp_state_remove_instance_nocalls() instead of
cpuhp_state_remove_instance() so that the notifiers don't execute after
the PMU device has been unregistered.

[will: Rewrote commit message]</Note>
    </Notes>
    <CVE>CVE-2023-52860</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: it66121: Fix invalid connector dereference

Fix the NULL pointer dereference when no monitor is connected, and the
sound card is opened from userspace.

Instead return an empty buffer (of zeroes) as the EDID information to
the sound framework if there is no connector attached.</Note>
    </Notes>
    <CVE>CVE-2023-52861</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: prevent potential string overflow

The dev-&gt;id value comes from ida_alloc() so it's a number between zero
and INT_MAX.  If it's too high then these sprintf()s will overflow.</Note>
    </Notes>
    <CVE>CVE-2023-52868</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-mt6765: 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-52870</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

soc: qcom: llcc: Handle a second device without data corruption

Usually there is only one llcc device. But if there were a second, even
a failed probe call would modify the global drv_data pointer. So check
if drv_data is valid before overwriting it.</Note>
    </Notes>
    <CVE>CVE-2023-52871</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tty: n_gsm: fix race condition in status line change on dead connections

gsm_cleanup_mux() cleans up the gsm by closing all DLCIs, stopping all
timers, removing the virtual tty devices and clearing the data queues.
This procedure, however, may cause subsequent changes of the virtual modem
status lines of a DLCI. More data is being added the outgoing data queue
and the deleted kick timer is restarted to handle this. At this point many
resources have already been removed by the cleanup procedure. Thus, a
kernel panic occurs.

Fix this by proving in gsm_modem_update() that the cleanup procedure has
not been started and the mux is still alive.

Note that writing to a virtual tty is already protected by checks against
the DLCI specific connection state.</Note>
    </Notes>
    <CVE>CVE-2023-52872</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-mt6779: 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-52873</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-mt7629-eth: 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-52876</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: typec: tcpm: Fix NULL pointer dereference in tcpm_pd_svdm()

It is possible that typec_register_partner() returns ERR_PTR on failure.
When port-&gt;partner is an error, a NULL pointer dereference may occur as
shown below.

[91222.095236][  T319] typec port0: failed to register partner (-17)
...
[91225.061491][  T319] Unable to handle kernel NULL pointer dereference
at virtual address 000000000000039f
[91225.274642][  T319] pc : tcpm_pd_data_request+0x310/0x13fc
[91225.274646][  T319] lr : tcpm_pd_data_request+0x298/0x13fc
[91225.308067][  T319] Call trace:
[91225.308070][  T319]  tcpm_pd_data_request+0x310/0x13fc
[91225.308073][  T319]  tcpm_pd_rx_handler+0x100/0x9e8
[91225.355900][  T319]  kthread_worker_fn+0x178/0x58c
[91225.355902][  T319]  kthread+0x150/0x200
[91225.355905][  T319]  ret_from_fork+0x10/0x30

Add a check for port-&gt;partner to avoid dereferencing a NULL pointer.</Note>
    </Notes>
    <CVE>CVE-2023-52877</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds

If the "struct can_priv::echoo_skb" is accessed out of bounds, this
would cause a kernel crash. Instead, issue a meaningful warning
message and return with an error.</Note>
    </Notes>
    <CVE>CVE-2023-52878</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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">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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 flaw was found in the Linux Kernel due to a race problem in the unix garbage collector's deletion of SKB races with unix_stream_read_generic() on the socket that the SKB is queued on.</Note>
    </Notes>
    <CVE>CVE-2023-6531</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Issue summary: Some non-default TLS server configurations can cause unbounded
memory growth when processing TLSv1.3 sessions

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

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

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

The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL
1.0.2 is also not affected by this issue.</Note>
    </Notes>
    <CVE>CVE-2024-2511</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qualcomm: rmnet: fix global oob in rmnet_policy

The variable rmnet_link_ops assign a *bigger* maxtype which leads to a
global out-of-bounds read when parsing the netlink attributes. See bug
trace below:

==================================================================
BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207

CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G                 N 6.1.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:284 [inline]
 print_report+0x172/0x475 mm/kasan/report.c:395
 kasan_report+0xbb/0x1c0 mm/kasan/report.c:495
 validate_nla lib/nlattr.c:386 [inline]
 __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
 __nla_parse+0x3e/0x50 lib/nlattr.c:697
 nla_parse_nested_deprecated include/net/netlink.h:1248 [inline]
 __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485
 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594
 rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091
 netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540
 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
 netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345
 netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921
 sock_sendmsg_nosec net/socket.c:714 [inline]
 sock_sendmsg+0x154/0x190 net/socket.c:734
 ____sys_sendmsg+0x6df/0x840 net/socket.c:2482
 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
 __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fdcf2072359
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359
RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003
RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000
 &lt;/TASK&gt;

The buggy address belongs to the variable:
 rmnet_policy+0x30/0xe0

The buggy address belongs to the physical page:
page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243
flags: 0x200000000001000(reserved|node=0|zone=2)
raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07
 ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9
&gt;ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9
                                                 ^
 ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9
 ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9

According to the comment of `nla_parse_nested_deprecated`, the maxtype
should be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here.</Note>
    </Notes>
    <CVE>CVE-2024-26597</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

smb: Fix regression in writes when non-standard maximum write size negotiated

The conversion to netfs in the 6.3 kernel caused a regression when
maximum write size is set by the server to an unexpected value which is
not a multiple of 4096 (similarly if the user overrides the maximum
write size by setting mount parm "wsize", but sets it to a value that
is not a multiple of 4096).  When negotiated write size is not a
multiple of 4096 the netfs code can skip the end of the final
page when doing large sequential writes, causing data corruption.

This section of code is being rewritten/removed due to a large
netfs change, but until that point (ie for the 6.3 kernel until now)
we can not support non-standard maximum write sizes.

Add a warning if a user specifies a wsize on mount that is not
a multiple of 4096 (and round down), also add a change where we
round down the maximum write size if the server negotiates a value
that is not a multiple of 4096 (we also have to check to make sure that
we do not round it down to zero).</Note>
    </Notes>
    <CVE>CVE-2024-26692</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove

In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the
VMBus channel"), napi_disable was getting called for all channels,
including all subchannels without confirming if they are enabled or not.

This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()
has finished running but nvdev-&gt;subchan_work has not started yet.
netvsc_subchan_work() -&gt; rndis_set_subchannel() has not created the
sub-channels and because of that netvsc_sc_open() is not running.
netvsc_remove() calls cancel_work_sync(&amp;nvdev-&gt;subchan_work), for which
netvsc_subchan_work did not run.

netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI
cannot be scheduled. Then netvsc_sc_open() -&gt; napi_enable will clear the
NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the
opposite.

Now during netvsc_device_remove(), when napi_disable is called for those
subchannels, napi_disable gets stuck on infinite msleep.

This fix addresses this problem by ensuring that napi_disable() is not
getting called for non-enabled NAPI struct.
But netif_napi_del() is still necessary for these non-enabled NAPI struct
for cleanup purpose.

Call trace:
[  654.559417] task:modprobe        state:D stack:    0 pid: 2321 ppid:  1091 flags:0x00004002
[  654.568030] Call Trace:
[  654.571221]  &lt;TASK&gt;
[  654.573790]  __schedule+0x2d6/0x960
[  654.577733]  schedule+0x69/0xf0
[  654.581214]  schedule_timeout+0x87/0x140
[  654.585463]  ? __bpf_trace_tick_stop+0x20/0x20
[  654.590291]  msleep+0x2d/0x40
[  654.593625]  napi_disable+0x2b/0x80
[  654.597437]  netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]
[  654.603935]  rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]
[  654.611101]  ? do_wait_intr+0xb0/0xb0
[  654.615753]  netvsc_remove+0x7c/0x120 [hv_netvsc]
[  654.621675]  vmbus_remove+0x27/0x40 [hv_vmbus]</Note>
    </Notes>
    <CVE>CVE-2024-26698</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: cdns3: fix memory double free when handle zero packet

829  if (request-&gt;complete) {
830          spin_unlock(&amp;priv_dev-&gt;lock);
831          usb_gadget_giveback_request(&amp;priv_ep-&gt;endpoint,
832                                    request);
833          spin_lock(&amp;priv_dev-&gt;lock);
834  }
835
836  if (request-&gt;buf == priv_dev-&gt;zlp_buf)
837      cdns3_gadget_ep_free_request(&amp;priv_ep-&gt;endpoint, request);

Driver append an additional zero packet request when queue a packet, which
length mod max packet size is 0. When transfer complete, run to line 831,
usb_gadget_giveback_request() will free this requestion. 836 condition is
true, so cdns3_gadget_ep_free_request() free this request again.

Log:

[ 1920.140696][  T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3]
[ 1920.140696][  T150]
[ 1920.151837][  T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):
[ 1920.159082][  T150]  cdns3_gadget_giveback+0x134/0x2c0 [cdns3]
[ 1920.164988][  T150]  cdns3_transfer_completed+0x438/0x5f8 [cdns3]

Add check at line 829, skip call usb_gadget_giveback_request() if it is
additional zero length packet request. Needn't call
usb_gadget_giveback_request() because it is allocated in this driver.</Note>
    </Notes>
    <CVE>CVE-2024-26748</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

md: Don't ignore suspended array in md_check_recovery()

mddev_suspend() never stop sync_thread, hence it doesn't make sense to
ignore suspended array in md_check_recovery(), which might cause
sync_thread can't be unregistered.

After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following
hang can be triggered by test shell/integrity-caching.sh:

1) suspend the array:
raid_postsuspend
 mddev_suspend

2) stop the array:
raid_dtr
 md_stop
  __md_stop_writes
   stop_sync_thread
    set_bit(MD_RECOVERY_INTR, &amp;mddev-&gt;recovery);
    md_wakeup_thread_directly(mddev-&gt;sync_thread);
    wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &amp;mddev-&gt;recovery))

3) sync thread done:
md_do_sync
 set_bit(MD_RECOVERY_DONE, &amp;mddev-&gt;recovery);
 md_wakeup_thread(mddev-&gt;thread);

4) daemon thread can't unregister sync thread:
md_check_recovery
 if (mddev-&gt;suspended)
   return; -&gt; return directly
 md_read_sync_thread
 clear_bit(MD_RECOVERY_RUNNING, &amp;mddev-&gt;recovery);
 -&gt; MD_RECOVERY_RUNNING can't be cleared, hence step 2 hang;

This problem is not just related to dm-raid, fix it by ignoring
suspended array in md_check_recovery(). And follow up patches will
improve dm-raid better to frozen sync thread during suspend.</Note>
    </Notes>
    <CVE>CVE-2024-26758</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fsl-qdma: init irq after reg initialization

Initialize the qDMA irqs after the registers are configured so that
interrupts that may have been pending from a primary kernel don't get
processed by the irq handler before it is ready to and cause panic with
the following trace:

  Call trace:
   fsl_qdma_queue_handler+0xf8/0x3e8
   __handle_irq_event_percpu+0x78/0x2b0
   handle_irq_event_percpu+0x1c/0x68
   handle_irq_event+0x44/0x78
   handle_fasteoi_irq+0xc8/0x178
   generic_handle_irq+0x24/0x38
   __handle_domain_irq+0x90/0x100
   gic_handle_irq+0x5c/0xb8
   el1_irq+0xb8/0x180
   _raw_spin_unlock_irqrestore+0x14/0x40
   __setup_irq+0x4bc/0x798
   request_threaded_irq+0xd8/0x190
   devm_request_threaded_irq+0x74/0xe8
   fsl_qdma_probe+0x4d4/0xca8
   platform_drv_probe+0x50/0xa0
   really_probe+0xe0/0x3f8
   driver_probe_device+0x64/0x130
   device_driver_attach+0x6c/0x78
   __driver_attach+0xbc/0x158
   bus_for_each_dev+0x5c/0x98
   driver_attach+0x20/0x28
   bus_add_driver+0x158/0x220
   driver_register+0x60/0x110
   __platform_driver_register+0x44/0x50
   fsl_qdma_driver_init+0x18/0x20
   do_one_initcall+0x48/0x258
   kernel_init_freeable+0x1a4/0x23c
   kernel_init+0x10/0xf8
   ret_from_fork+0x10/0x18</Note>
    </Notes>
    <CVE>CVE-2024-26788</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Avoid potential use-after-free in hci_error_reset

While handling the HCI_EV_HARDWARE_ERROR event, if the underlying
BT controller is not responding, the GPIO reset mechanism would
free the hci_dev and lead to a use-after-free in hci_error_reset.

Here's the call trace observed on a ChromeOS device with Intel AX201:
   queue_work_on+0x3e/0x6c
   __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth &lt;HASH:3b4a6&gt;]
   ? init_wait_entry+0x31/0x31
   __hci_cmd_sync+0x16/0x20 [bluetooth &lt;HASH:3b4a 6&gt;]
   hci_error_reset+0x4f/0xa4 [bluetooth &lt;HASH:3b4a 6&gt;]
   process_one_work+0x1d8/0x33f
   worker_thread+0x21b/0x373
   kthread+0x13a/0x152
   ? pr_cont_work+0x54/0x54
   ? kthread_blkcg+0x31/0x31
    ret_from_fork+0x1f/0x30

This patch holds the reference count on the hci_dev while processing
a HCI_EV_HARDWARE_ERROR event to avoid potential crash.</Note>
    </Notes>
    <CVE>CVE-2024-26801</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: set correct id, uid and cruid for multiuser automounts

When uid, gid and cruid are not specified, we need to dynamically
set them into the filesystem context used for automounting otherwise
they'll end up reusing the values from the parent mount.</Note>
    </Notes>
    <CVE>CVE-2024-26822</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: ir_toy: fix a memleak in irtoy_tx

When irtoy_command fails, buf should be freed since it is allocated by
irtoy_tx, or there is a memleak.</Note>
    </Notes>
    <CVE>CVE-2024-26829</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/irdma: Fix KASAN issue with tasklet

KASAN testing revealed the following issue assocated with freeing an IRQ.

[50006.466686] Call Trace:
[50006.466691]  &lt;IRQ&gt;
[50006.489538]  dump_stack+0x5c/0x80
[50006.493475]  print_address_description.constprop.6+0x1a/0x150
[50006.499872]  ? irdma_sc_process_ceq+0x483/0x790 [irdma]
[50006.505742]  ? irdma_sc_process_ceq+0x483/0x790 [irdma]
[50006.511644]  kasan_report.cold.11+0x7f/0x118
[50006.516572]  ? irdma_sc_process_ceq+0x483/0x790 [irdma]
[50006.522473]  irdma_sc_process_ceq+0x483/0x790 [irdma]
[50006.528232]  irdma_process_ceq+0xb2/0x400 [irdma]
[50006.533601]  ? irdma_hw_flush_wqes_callback+0x370/0x370 [irdma]
[50006.540298]  irdma_ceq_dpc+0x44/0x100 [irdma]
[50006.545306]  tasklet_action_common.isra.14+0x148/0x2c0
[50006.551096]  __do_softirq+0x1d0/0xaf8
[50006.555396]  irq_exit_rcu+0x219/0x260
[50006.559670]  irq_exit+0xa/0x20
[50006.563320]  smp_apic_timer_interrupt+0x1bf/0x690
[50006.568645]  apic_timer_interrupt+0xf/0x20
[50006.573341]  &lt;/IRQ&gt;

The issue is that a tasklet could be pending on another core racing
the delete of the irq.

Fix by insuring any scheduled tasklet is killed after deleting the
irq.</Note>
    </Notes>
    <CVE>CVE-2024-26838</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102

A call to listxattr() with a buffer size = 0 returns the actual
size of the buffer needed for a subsequent call. When size &gt; 0,
nfs4_listxattr() does not return an error because either
generic_listxattr() or nfs4_listxattr_nfs4_label() consumes
exactly all the bytes then size is 0 when calling
nfs4_listxattr_nfs4_user() which then triggers the following
kernel BUG:

  [   99.403778] kernel BUG at mm/usercopy.c:102!
  [   99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
  [   99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1
  [   99.415827] Call trace:
  [   99.415985]  usercopy_abort+0x70/0xa0
  [   99.416227]  __check_heap_object+0x134/0x158
  [   99.416505]  check_heap_object+0x150/0x188
  [   99.416696]  __check_object_size.part.0+0x78/0x168
  [   99.416886]  __check_object_size+0x28/0x40
  [   99.417078]  listxattr+0x8c/0x120
  [   99.417252]  path_listxattr+0x78/0xe0
  [   99.417476]  __arm64_sys_listxattr+0x28/0x40
  [   99.417723]  invoke_syscall+0x78/0x100
  [   99.417929]  el0_svc_common.constprop.0+0x48/0xf0
  [   99.418186]  do_el0_svc+0x24/0x38
  [   99.418376]  el0_svc+0x3c/0x110
  [   99.418554]  el0t_64_sync_handler+0x120/0x130
  [   99.418788]  el0t_64_sync+0x194/0x198
  [   99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)

Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl',
thus calling lisxattr() with size = 16 will trigger the bug.

Add check on nfs4_listxattr() to return ERANGE error when it is
called with size &gt; 0 and the return value is greater than size.</Note>
    </Notes>
    <CVE>CVE-2024-26870</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_core: Fix possible buffer overflow

struct hci_dev_info has a fixed size name[8] field so in the event that
hdev-&gt;name is bigger than that strcpy would attempt to write past its
size, so this fixes this problem by switching to use strscpy.</Note>
    </Notes>
    <CVE>CVE-2024-26889</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

Revert "drm/amd: flush any delayed gfxoff on suspend entry"

commit ab4750332dbe ("drm/amdgpu/sdma5.2: add begin/end_use ring
callbacks") caused GFXOFF control to be used more heavily and the
codepath that was removed from commit 0dee72639533 ("drm/amd: flush any
delayed gfxoff on suspend entry") now can be exercised at suspend again.

Users report that by using GNOME to suspend the lockscreen trigger will
cause SDMA traffic and the system can deadlock.

This reverts commit 0dee726395333fea833eaaf838bc80962df886c8.</Note>
    </Notes>
    <CVE>CVE-2024-26916</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: release mutex after nft_gc_seq_end from abort path

The commit mutex should not be released during the critical section
between nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC
worker could collect expired objects and get the released commit lock
within the same GC sequence.

nf_tables_module_autoload() temporarily releases the mutex to load
module dependencies, then it goes back to replay the transaction again.
Move it at the end of the abort phase after nft_gc_seq_end() is called.</Note>
    </Notes>
    <CVE>CVE-2024-26925</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">unknown</Note>
    </Notes>
    <CVE>CVE-2024-269355</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/i915/gt: Reset queue_priority_hint on parking

Originally, with strict in order execution, we could complete execution
only when the queue was empty. Preempt-to-busy allows replacement of an
active request that may complete before the preemption is processed by
HW. If that happens, the request is retired from the queue, but the
queue_priority_hint remains set, preventing direct submission until
after the next CS interrupt is processed.

This preempt-to-busy race can be triggered by the heartbeat, which will
also act as the power-management barrier and upon completion allow us to
idle the HW. We may process the completion of the heartbeat, and begin
parking the engine before the CS event that restores the
queue_priority_hint, causing us to fail the assertion that it is MIN.

&lt;3&gt;[  166.210729] __engine_park:283 GEM_BUG_ON(engine-&gt;sched_engine-&gt;queue_priority_hint != (-((int)(~0U &gt;&gt; 1)) - 1))
&lt;0&gt;[  166.210781] Dumping ftrace buffer:
&lt;0&gt;[  166.210795] ---------------------------------
...
&lt;0&gt;[  167.302811] drm_fdin-1097      2..s1. 165741070us : trace_ports: 0000:00:02.0 rcs0: promote { ccid:20 1217:2 prio 0 }
&lt;0&gt;[  167.302861] drm_fdin-1097      2d.s2. 165741072us : execlists_submission_tasklet: 0000:00:02.0 rcs0: preempting last=1217:2, prio=0, hint=2147483646
&lt;0&gt;[  167.302928] drm_fdin-1097      2d.s2. 165741072us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 1217:2, current 0
&lt;0&gt;[  167.302992] drm_fdin-1097      2d.s2. 165741073us : __i915_request_submit: 0000:00:02.0 rcs0: fence 3:4660, current 4659
&lt;0&gt;[  167.303044] drm_fdin-1097      2d.s1. 165741076us : execlists_submission_tasklet: 0000:00:02.0 rcs0: context:3 schedule-in, ccid:40
&lt;0&gt;[  167.303095] drm_fdin-1097      2d.s1. 165741077us : trace_ports: 0000:00:02.0 rcs0: submit { ccid:40 3:4660* prio 2147483646 }
&lt;0&gt;[  167.303159] kworker/-89       11..... 165741139us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence c90:2, current 2
&lt;0&gt;[  167.303208] kworker/-89       11..... 165741148us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:c90 unpin
&lt;0&gt;[  167.303272] kworker/-89       11..... 165741159us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 1217:2, current 2
&lt;0&gt;[  167.303321] kworker/-89       11..... 165741166us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:1217 unpin
&lt;0&gt;[  167.303384] kworker/-89       11..... 165741170us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 3:4660, current 4660
&lt;0&gt;[  167.303434] kworker/-89       11d..1. 165741172us : __intel_context_retire: 0000:00:02.0 rcs0: context:1216 retire runtime: { total:56028ns, avg:56028ns }
&lt;0&gt;[  167.303484] kworker/-89       11..... 165741198us : __engine_park: 0000:00:02.0 rcs0: parked
&lt;0&gt;[  167.303534]   &lt;idle&gt;-0         5d.H3. 165741207us : execlists_irq_handler: 0000:00:02.0 rcs0: semaphore yield: 00000040
&lt;0&gt;[  167.303583] kworker/-89       11..... 165741397us : __intel_context_retire: 0000:00:02.0 rcs0: context:1217 retire runtime: { total:325575ns, avg:0ns }
&lt;0&gt;[  167.303756] kworker/-89       11..... 165741777us : __intel_context_retire: 0000:00:02.0 rcs0: context:c90 retire runtime: { total:0ns, avg:0ns }
&lt;0&gt;[  167.303806] kworker/-89       11..... 165742017us : __engine_park: __engine_park:283 GEM_BUG_ON(engine-&gt;sched_engine-&gt;queue_priority_hint != (-((int)(~0U &gt;&gt; 1)) - 1))
&lt;0&gt;[  167.303811] ---------------------------------
&lt;4&gt;[  167.304722] ------------[ cut here ]------------
&lt;2&gt;[  167.304725] kernel BUG at drivers/gpu/drm/i915/gt/intel_engine_pm.c:283!
&lt;4&gt;[  167.304731] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
&lt;4&gt;[  167.304734] CPU: 11 PID: 89 Comm: kworker/11:1 Tainted: G        W          6.8.0-rc2-CI_DRM_14193-gc655e0fd2804+ #1
&lt;4&gt;[  167.304736] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022
&lt;4&gt;[  167.304738] Workqueue: i915-unordered retire_work_handler [i915]
&lt;4&gt;[  16
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26937</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode()

If we have no VBT, or the VBT didn't declare the encoder
in question, we won't have the 'devdata' for the encoder.
Instead of oopsing just bail early.

We won't be able to tell whether the port is DP++ or not,
but so be it.

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

drm/vmwgfx: Create debugfs ttm_resource_manager entry only if needed

The driver creates /sys/kernel/debug/dri/0/mob_ttm even when the
corresponding ttm_resource_manager is not allocated.
This leads to a crash when trying to read from this file.

Add a check to create mob_ttm, system_mob_ttm, and gmr_ttm debug file
only when the corresponding ttm_resource_manager is allocated.

crash&gt; bt
PID: 3133409  TASK: ffff8fe4834a5000  CPU: 3    COMMAND: "grep"
 #0 [ffffb954506b3b20] machine_kexec at ffffffffb2a6bec3
 #1 [ffffb954506b3b78] __crash_kexec at ffffffffb2bb598a
 #2 [ffffb954506b3c38] crash_kexec at ffffffffb2bb68c1
 #3 [ffffb954506b3c50] oops_end at ffffffffb2a2a9b1
 #4 [ffffb954506b3c70] no_context at ffffffffb2a7e913
 #5 [ffffb954506b3cc8] __bad_area_nosemaphore at ffffffffb2a7ec8c
 #6 [ffffb954506b3d10] do_page_fault at ffffffffb2a7f887
 #7 [ffffb954506b3d40] page_fault at ffffffffb360116e
    [exception RIP: ttm_resource_manager_debug+0x11]
    RIP: ffffffffc04afd11  RSP: ffffb954506b3df0  RFLAGS: 00010246
    RAX: ffff8fe41a6d1200  RBX: 0000000000000000  RCX: 0000000000000940
    RDX: 0000000000000000  RSI: ffffffffc04b4338  RDI: 0000000000000000
    RBP: ffffb954506b3e08   R8: ffff8fee3ffad000   R9: 0000000000000000
    R10: ffff8fe41a76a000  R11: 0000000000000001  R12: 00000000ffffffff
    R13: 0000000000000001  R14: ffff8fe5bb6f3900  R15: ffff8fe41a6d1200
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #8 [ffffb954506b3e00] ttm_resource_manager_show at ffffffffc04afde7 [ttm]
 #9 [ffffb954506b3e30] seq_read at ffffffffb2d8f9f3
    RIP: 00007f4c4eda8985  RSP: 00007ffdbba9e9f8  RFLAGS: 00000246
    RAX: ffffffffffffffda  RBX: 000000000037e000  RCX: 00007f4c4eda8985
    RDX: 000000000037e000  RSI: 00007f4c41573000  RDI: 0000000000000003
    RBP: 000000000037e000   R8: 0000000000000000   R9: 000000000037fe30
    R10: 0000000000000000  R11: 0000000000000246  R12: 00007f4c41573000
    R13: 0000000000000003  R14: 00007f4c41572010  R15: 0000000000000003
    ORIG_RAX: 0000000000000000  CS: 0033  SS: 002b</Note>
    </Notes>
    <CVE>CVE-2024-26940</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/dmem: handle kcalloc() allocation failure

The kcalloc() in nouveau_dmem_evict_chunk() will return null if
the physical memory has run out. As a result, if we dereference
src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs
will happen.

Moreover, the GPU is going away. If the kcalloc() fails, we could not
evict all pages mapping a chunk. So this patch adds a __GFP_NOFAIL
flag in kcalloc().

Finally, as there is no need to have physically contiguous memory,
this patch switches kcalloc() to kvcalloc() in order to avoid
failing allocations.</Note>
    </Notes>
    <CVE>CVE-2024-26943</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Add error handling in xhci_map_urb_for_dma

Currently xhci_map_urb_for_dma() creates a temporary buffer and copies
the SG list to the new linear buffer. But if the kzalloc_node() fails,
then the following sg_pcopy_to_buffer() can lead to crash since it
tries to memcpy to NULL pointer.

So return -ENOMEM if kzalloc returns null pointer.</Note>
    </Notes>
    <CVE>CVE-2024-26964</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 - resolve race condition during AER recovery

During the PCI AER system's error recovery process, the kernel driver
may encounter a race condition with freeing the reset_data structure's
memory. If the device restart will take more than 10 seconds the function
scheduling that restart will exit due to a timeout, and the reset_data
structure will be freed. However, this data structure is used for
completion notification after the restart is completed, which leads
to a UAF bug.

This results in a KFENCE bug notice.

  BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]
  Use-after-free read at 0x00000000bc56fddf (in kfence-#142):
  adf_device_reset_worker+0x38/0xa0 [intel_qat]
  process_one_work+0x173/0x340

To resolve this race condition, the memory associated to the container
of the work_struct is freed on the worker if the timeout expired,
otherwise on the function that schedules the worker.
The timeout detection can be done by checking if the caller is
still waiting for completion or not by using completion_done() function.</Note>
    </Notes>
    <CVE>CVE-2024-26974</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_iounmap(): Fix MMIO mapping leak

The #ifdef ARCH_HAS_GENERIC_IOPORT_MAP accidentally also guards iounmap(),
which means MMIO mappings are leaked.

Move the guard so we call iounmap() for MMIO mappings.</Note>
    </Notes>
    <CVE>CVE-2024-26977</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

init/main.c: Fix potential static_command_line memory overflow

We allocate memory of size 'xlen + strlen(boot_command_line) + 1' for
static_command_line, but the strings copied into static_command_line are
extra_command_line and command_line, rather than extra_command_line and
boot_command_line.

When strlen(command_line) &gt; strlen(boot_command_line), static_command_line
will overflow.

This patch just recovers strlen(command_line) which was miss-consolidated
with strlen(boot_command_line) in the commit f5c7310ac73e ("init/main: add
checks for the return value of memblock_alloc*()")</Note>
    </Notes>
    <CVE>CVE-2024-26988</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arm64: hibernate: Fix level3 translation fault in swsusp_save()

On arm64 machines, swsusp_save() faults if it attempts to access
MEMBLOCK_NOMAP memory ranges. This can be reproduced in QEMU using UEFI
when booting with rodata=off debug_pagealloc=off and CONFIG_KFENCE=n:

  Unable to handle kernel paging request at virtual address ffffff8000000000
  Mem abort info:
    ESR = 0x0000000096000007
    EC = 0x25: DABT (current EL), IL = 32 bits
    SET = 0, FnV = 0
    EA = 0, S1PTW = 0
    FSC = 0x07: level 3 translation fault
  Data abort info:
    ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000
    CM = 0, WnR = 0, TnD = 0, TagAccess = 0
    GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
  swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000eeb0b000
  [ffffff8000000000] pgd=180000217fff9803, p4d=180000217fff9803, pud=180000217fff9803, pmd=180000217fff8803, pte=0000000000000000
  Internal error: Oops: 0000000096000007 [#1] SMP
  Internal error: Oops: 0000000096000007 [#1] SMP
  Modules linked in: xt_multiport ipt_REJECT nf_reject_ipv4 xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter rfkill at803x snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg dwmac_generic stmmac_platform snd_hda_codec stmmac joydev pcs_xpcs snd_hda_core phylink ppdev lp parport ramoops reed_solomon ip_tables x_tables nls_iso8859_1 vfat multipath linear amdgpu amdxcp drm_exec gpu_sched drm_buddy hid_generic usbhid hid radeon video drm_suballoc_helper drm_ttm_helper ttm i2c_algo_bit drm_display_helper cec drm_kms_helper drm
  CPU: 0 PID: 3663 Comm: systemd-sleep Not tainted 6.6.2+ #76
  Source Version: 4e22ed63a0a48e7a7cff9b98b7806d8d4add7dc0
  Hardware name: Greatwall GW-XXXXXX-XXX/GW-XXXXXX-XXX, BIOS KunLun BIOS V4.0 01/19/2021
  pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
  pc : swsusp_save+0x280/0x538
  lr : swsusp_save+0x280/0x538
  sp : ffffffa034a3fa40
  x29: ffffffa034a3fa40 x28: ffffff8000001000 x27: 0000000000000000
  x26: ffffff8001400000 x25: ffffffc08113e248 x24: 0000000000000000
  x23: 0000000000080000 x22: ffffffc08113e280 x21: 00000000000c69f2
  x20: ffffff8000000000 x19: ffffffc081ae2500 x18: 0000000000000000
  x17: 6666662074736420 x16: 3030303030303030 x15: 3038666666666666
  x14: 0000000000000b69 x13: ffffff9f89088530 x12: 00000000ffffffea
  x11: 00000000ffff7fff x10: 00000000ffff7fff x9 : ffffffc08193f0d0
  x8 : 00000000000bffe8 x7 : c0000000ffff7fff x6 : 0000000000000001
  x5 : ffffffa0fff09dc8 x4 : 0000000000000000 x3 : 0000000000000027
  x2 : 0000000000000000 x1 : 0000000000000000 x0 : 000000000000004e
  Call trace:
   swsusp_save+0x280/0x538
   swsusp_arch_suspend+0x148/0x190
   hibernation_snapshot+0x240/0x39c
   hibernate+0xc4/0x378
   state_store+0xf0/0x10c
   kobj_attr_store+0x14/0x24

The reason is swsusp_save() -&gt; copy_data_pages() -&gt; page_is_saveable()
-&gt; kernel_page_present() assuming that a page is always present when
can_set_direct_map() is false (all of rodata_full,
debug_pagealloc_enabled() and arm64_kfence_can_set_direct_map() false),
irrespective of the MEMBLOCK_NOMAP ranges. Such MEMBLOCK_NOMAP regions
should not be saved during hibernation.

This problem was introduced by changes to the pfn_valid() logic in
commit a7d9f306ba70 ("arm64: drop pfn_valid_within() and simplify
pfn_valid()").

Similar to other architectures, drop the !can_set_direct_map() check in
kernel_page_present() so that page_is_savable() skips such pages.

[catalin.marinas@arm.com: rework commit message]</Note>
    </Notes>
    <CVE>CVE-2024-26989</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

speakup: Avoid crash on very long word

In case a console is set up really large and contains a really long word
(&gt; 256 characters), we have to stop before the length of the word buffer.</Note>
    </Notes>
    <CVE>CVE-2024-26994</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: host: Fix dereference issue in DDMA completion flow.

Fixed variable dereference issue in DDMA completion flow.</Note>
    </Notes>
    <CVE>CVE-2024-26997</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pmac_zilog: Remove flawed mitigation for rx irq flood

The mitigation was intended to stop the irq completely. That may be
better than a hard lock-up but it turns out that you get a crash anyway
if you're using pmac_zilog as a serial console:

ttyPZ0: pmz: rx irq flood !
BUG: spinlock recursion on CPU#0, swapper/0

That's because the pr_err() call in pmz_receive_chars() results in
pmz_console_write() attempting to lock a spinlock already locked in
pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal
BUG splat. The spinlock in question is the one in struct uart_port.

Even when it's not fatal, the serial port rx function ceases to work.
Also, the iteration limit doesn't play nicely with QEMU, as can be
seen in the bug report linked below.

A web search for other reports of the error message "pmz: rx irq flood"
didn't produce anything. So I don't think this code is needed any more.
Remove it.</Note>
    </Notes>
    <CVE>CVE-2024-26999</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mxs-auart: add spinlock around changing cts state

The uart_handle_cts_change() function in serial_core expects the caller
to hold uport-&gt;lock. For example, I have seen the below kernel splat,
when the Bluetooth driver is loaded on an i.MX28 board.

    [   85.119255] ------------[ cut here ]------------
    [   85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec
    [   85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs
    [   85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1
    [   85.151396] Hardware name: Freescale MXS (Device Tree)
    [   85.156679] Workqueue: hci0 hci_power_on [bluetooth]
    (...)
    [   85.191765]  uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4
    [   85.198787]  mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210
    (...)</Note>
    </Notes>
    <CVE>CVE-2024-27000</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

comedi: vmk80xx: fix incomplete endpoint checking

While vmk80xx does have endpoint checking implemented, some things
can fall through the cracks. Depending on the hardware model,
URBs can have either bulk or interrupt type, and current version
of vmk80xx_find_usb_endpoints() function does not take that fully
into account. While this warning does not seem to be too harmful,
at the very least it will crash systems with 'panic_on_warn' set on
them.

Fix the issue found by Syzkaller [1] by somewhat simplifying the
endpoint checking process with usb_find_common_endpoints() and
ensuring that only expected endpoint types are present.

This patch has not been tested on real hardware.

[1] Syzkaller report:
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503
...
Call Trace:
 &lt;TASK&gt;
 usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59
 vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]
 vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818
 comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067
 usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399
...

Similar issue also found by Syzkaller:</Note>
    </Notes>
    <CVE>CVE-2024-27001</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Get runtime PM before walking tree during disable_unused

Doug reported [1] the following hung task:

 INFO: task swapper/0:1 blocked for more than 122 seconds.
       Not tainted 5.15.149-21875-gf795ebc40eb8 #1
 "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 task:swapper/0       state:D stack:    0 pid:    1 ppid:     0 flags:0x00000008
 Call trace:
  __switch_to+0xf4/0x1f4
  __schedule+0x418/0xb80
  schedule+0x5c/0x10c
  rpm_resume+0xe0/0x52c
  rpm_resume+0x178/0x52c
  __pm_runtime_resume+0x58/0x98
  clk_pm_runtime_get+0x30/0xb0
  clk_disable_unused_subtree+0x58/0x208
  clk_disable_unused_subtree+0x38/0x208
  clk_disable_unused_subtree+0x38/0x208
  clk_disable_unused_subtree+0x38/0x208
  clk_disable_unused_subtree+0x38/0x208
  clk_disable_unused+0x4c/0xe4
  do_one_initcall+0xcc/0x2d8
  do_initcall_level+0xa4/0x148
  do_initcalls+0x5c/0x9c
  do_basic_setup+0x24/0x30
  kernel_init_freeable+0xec/0x164
  kernel_init+0x28/0x120
  ret_from_fork+0x10/0x20
 INFO: task kworker/u16:0:9 blocked for more than 122 seconds.
       Not tainted 5.15.149-21875-gf795ebc40eb8 #1
 "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 task:kworker/u16:0   state:D stack:    0 pid:    9 ppid:     2 flags:0x00000008
 Workqueue: events_unbound deferred_probe_work_func
 Call trace:
  __switch_to+0xf4/0x1f4
  __schedule+0x418/0xb80
  schedule+0x5c/0x10c
  schedule_preempt_disabled+0x2c/0x48
  __mutex_lock+0x238/0x488
  __mutex_lock_slowpath+0x1c/0x28
  mutex_lock+0x50/0x74
  clk_prepare_lock+0x7c/0x9c
  clk_core_prepare_lock+0x20/0x44
  clk_prepare+0x24/0x30
  clk_bulk_prepare+0x40/0xb0
  mdss_runtime_resume+0x54/0x1c8
  pm_generic_runtime_resume+0x30/0x44
  __genpd_runtime_resume+0x68/0x7c
  genpd_runtime_resume+0x108/0x1f4
  __rpm_callback+0x84/0x144
  rpm_callback+0x30/0x88
  rpm_resume+0x1f4/0x52c
  rpm_resume+0x178/0x52c
  __pm_runtime_resume+0x58/0x98
  __device_attach+0xe0/0x170
  device_initial_probe+0x1c/0x28
  bus_probe_device+0x3c/0x9c
  device_add+0x644/0x814
  mipi_dsi_device_register_full+0xe4/0x170
  devm_mipi_dsi_device_register_full+0x28/0x70
  ti_sn_bridge_probe+0x1dc/0x2c0
  auxiliary_bus_probe+0x4c/0x94
  really_probe+0xcc/0x2c8
  __driver_probe_device+0xa8/0x130
  driver_probe_device+0x48/0x110
  __device_attach_driver+0xa4/0xcc
  bus_for_each_drv+0x8c/0xd8
  __device_attach+0xf8/0x170
  device_initial_probe+0x1c/0x28
  bus_probe_device+0x3c/0x9c
  deferred_probe_work_func+0x9c/0xd8
  process_one_work+0x148/0x518
  worker_thread+0x138/0x350
  kthread+0x138/0x1e0
  ret_from_fork+0x10/0x20

The first thread is walking the clk tree and calling
clk_pm_runtime_get() to power on devices required to read the clk
hardware via struct clk_ops::is_enabled(). This thread holds the clk
prepare_lock, and is trying to runtime PM resume a device, when it finds
that the device is in the process of resuming so the thread schedule()s
away waiting for the device to finish resuming before continuing. The
second thread is runtime PM resuming the same device, but the runtime
resume callback is calling clk_prepare(), trying to grab the
prepare_lock waiting on the first thread.

This is a classic ABBA deadlock. To properly fix the deadlock, we must
never runtime PM resume or suspend a device with the clk prepare_lock
held. Actually doing that is near impossible today because the global
prepare_lock would have to be dropped in the middle of the tree, the
device runtime PM resumed/suspended, and then the prepare_lock grabbed
again to ensure consistency of the clk tree topology. If anything
changes with the clk tree in the meantime, we've lost and will need to
start the operation all over again.

Luckily, most of the time we're simply incrementing or decrementing the
runtime PM count on an active device, so we don't have the chance to
schedule away with the prepare_lock held. Let's fix this immediate
problem that can be
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-27004</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm: 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-mt65xx: Fix NULL pointer access in interrupt handler

The TX buffer in spi_transfer can be a NULL pointer, so the interrupt
handler may end up writing to the invalid memory and cause crashes.

Add a check to trans-&gt;tx_buf before using it.</Note>
    </Notes>
    <CVE>CVE-2024-27028</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: zynq: Prevent null pointer dereference caused by kmalloc failure

The kmalloc() in zynq_clk_setup() will return null if the
physical memory has run out. As a result, if we use snprintf()
to write data to the null address, the null pointer dereference
bug will happen.

This patch uses a stack variable to replace the kmalloc().</Note>
    </Notes>
    <CVE>CVE-2024-27037</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 a potential buffer overflow in 'dp_dsc_clock_en_read()'

Tell snprintf() to store at most 10 bytes in the output buffer
instead of 30.

Fixes the below:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10</Note>
    </Notes>
    <CVE>CVE-2024-27045</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: phy: fix phy_get_internal_delay accessing an empty array

The phy_get_internal_delay function could try to access to an empty
array in the case that the driver is calling phy_get_internal_delay
without defining delay_values and rx-internal-delay-ps or
tx-internal-delay-ps is defined to 0 in the device-tree.
This will lead to "unable to handle kernel NULL pointer dereference at
virtual address 0". To avoid this kernel oops, the test should be delay
&gt;= 0. As there is already delay &lt; 0 test just before, the test could
only be size == 0.</Note>
    </Notes>
    <CVE>CVE-2024-27047</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value

cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it
and return 0 in case of error.

Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
    </Notes>
    <CVE>CVE-2024-27051</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rtl8xxxu: add cancel_work_sync() for c2hcmd_work

The workqueue might still be running, when the driver is stopped. To
avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().</Note>
    </Notes>
    <CVE>CVE-2024-27052</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: wilc1000: fix RCU usage in connect path

With lockdep enabled, calls to the connect function from cfg802.11 layer
lead to the following warning:

=============================
WARNING: suspicious RCU usage
6.7.0-rc1-wt+ #333 Not tainted
-----------------------------
drivers/net/wireless/microchip/wilc1000/hif.c:386
suspicious rcu_dereference_check() usage!
[...]
stack backtrace:
CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333
Hardware name: Atmel SAMA5
 unwind_backtrace from show_stack+0x18/0x1c
 show_stack from dump_stack_lvl+0x34/0x48
 dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4
 wilc_parse_join_bss_param from connect+0x2c4/0x648
 connect from cfg80211_connect+0x30c/0xb74
 cfg80211_connect from nl80211_connect+0x860/0xa94
 nl80211_connect from genl_rcv_msg+0x3fc/0x59c
 genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8
 netlink_rcv_skb from genl_rcv+0x2c/0x3c
 genl_rcv from netlink_unicast+0x3b0/0x550
 netlink_unicast from netlink_sendmsg+0x368/0x688
 netlink_sendmsg from ____sys_sendmsg+0x190/0x430
 ____sys_sendmsg from ___sys_sendmsg+0x110/0x158
 ___sys_sendmsg from sys_sendmsg+0xe8/0x150
 sys_sendmsg from ret_fast_syscall+0x0/0x1c

This warning is emitted because in the connect path, when trying to parse
target BSS parameters, we dereference a RCU pointer whithout being in RCU
critical section.
Fix RCU dereference usage by moving it to a RCU read critical section. To
avoid wrapping the whole wilc_parse_join_bss_param under the critical
section, just use the critical section to copy ies data</Note>
    </Notes>
    <CVE>CVE-2024-27053</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: imx: csc/scaler: fix v4l2_ctrl_handler memory leak

Free the memory allocated in v4l2_ctrl_handler_init on release.</Note>
    </Notes>
    <CVE>CVE-2024-27076</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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-mem2mem: fix a memleak in v4l2_m2m_register_entity

The entity-&gt;name (i.e. name) is allocated in v4l2_m2m_register_entity
but isn't freed in its following error-handling paths. This patch
adds such deallocation to prevent memleak of entity-&gt;name.</Note>
    </Notes>
    <CVE>CVE-2024-27077</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: once more fix the call oder in amdgpu_ttm_move() v2

This reverts drm/amdgpu: fix ftrace event amdgpu_bo_move always move
on same heap. The basic problem here is that after the move the old
location is simply not available any more.

Some fixes were suggested, but essentially we should call the move
notification before actually moving things because only this way we have
the correct order for DMA-buf and VM move notifications as well.

Also rework the statistic handling so that we don't update the eviction
counter before the move.

v2: add missing NULL check</Note>
    </Notes>
    <CVE>CVE-2024-27400</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ncm: Avoid dropping datagrams of properly parsed NTBs

It is observed sometimes when tethering is used over NCM with Windows 11
as host, at some instances, the gadget_giveback has one byte appended at
the end of a proper NTB. When the NTB is parsed, unwrap call looks for
any leftover bytes in SKB provided by u_ether and if there are any pending
bytes, it treats them as a separate NTB and parses it. But in case the
second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that
were parsed properly in the first NTB and saved in rx_list are dropped.

Adding a few custom traces showed the following:
[002] d..1  7828.532866: dwc3_gadget_giveback: ep1out:
req 000000003868811a length 1025/16384 zsI ==&gt; 0
[002] d..1  7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025
[002] d..1  7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342
[002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67
[002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400
[002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10
[002] d..1  7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames

In this case, the giveback is of 1025 bytes and block length is 1024.
The rest 1 byte (which is 0x00) won't be parsed resulting in drop of
all datagrams in rx_list.

Same is case with packets of size 2048:
[002] d..1  7828.557948: dwc3_gadget_giveback: ep1out:
req 0000000011dfd96e length 2049/16384 zsI ==&gt; 0
[002] d..1  7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342
[002] d..1  7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800

Lecroy shows one byte coming in extra confirming that the byte is coming
in from PC:

 Transfer 2959 - Bytes Transferred(1025)  Timestamp((18.524 843 590)
 - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590)
 --- Packet 4063861
       Data(1024 bytes)
       Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590)
 --- Packet 4063863
       Data(1 byte)
       Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)

According to Windows driver, no ZLP is needed if wBlockLength is non-zero,
because the non-zero wBlockLength has already told the function side the
size of transfer to be expected. However, there are in-market NCM devices
that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize.
To deal with such devices, it pads an extra 0 at end so the transfer is no
longer multiple of wMaxPacketSize.</Note>
    </Notes>
    <CVE>CVE-2024-27405</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

power: supply: bq27xxx-i2c: Do not free non existing IRQ

The bq27xxx i2c-client may not have an IRQ, in which case
client-&gt;irq will be 0. bq27xxx_battery_i2c_probe() already has
an if (client-&gt;irq) check wrapping the request_threaded_irq().

But bq27xxx_battery_i2c_remove() unconditionally calls
free_irq(client-&gt;irq) leading to:

[  190.310742] ------------[ cut here ]------------
[  190.310843] Trying to free already-free IRQ 0
[  190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310

Followed by a backtrace when unbinding the driver. Add
an if (client-&gt;irq) to bq27xxx_battery_i2c_remove() mirroring
probe() to fix this.</Note>
    </Notes>
    <CVE>CVE-2024-27412</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

efi/capsule-loader: fix incorrect allocation size

gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures
is not enough for a 64-bit phys_addr_t:

drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open':
drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size]
  295 |         cap_info-&gt;phys = kzalloc(sizeof(void *), GFP_KERNEL);
      |                        ^

Use the correct type instead here.</Note>
    </Notes>
    <CVE>CVE-2024-27413</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST

If we received HCI_EV_IO_CAPA_REQUEST while
HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote
does support SSP since otherwise this event shouldn't be generated.</Note>
    </Notes>
    <CVE>CVE-2024-27416</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential "struct net" leak in inet6_rtm_getaddr()

It seems that if userspace provides a correct IFA_TARGET_NETNSID value
but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr()
returns -EINVAL with an elevated "struct net" refcount.</Note>
    </Notes>
    <CVE>CVE-2024-27417</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

cpumap: Zero-initialise xdp_rxq_info struct before running XDP program

When running an XDP program that is attached to a cpumap entry, we don't
initialise the xdp_rxq_info data structure being used in the xdp_buff
that backs the XDP program invocation. Tobias noticed that this leads to
random values being returned as the xdp_md-&gt;rx_queue_index value for XDP
programs running in a cpumap.

This means we're basically returning the contents of the uninitialised
memory, which is bad. Fix this by zero-initialising the rxq data
structure before running the XDP program.</Note>
    </Notes>
    <CVE>CVE-2024-27431</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nvme: fix reconnection fail due to reserved tag allocation

We found a issue on production environment while using NVMe over RDMA,
admin_q reconnect failed forever while remote target and network is ok.
After dig into it, we found it may caused by a ABBA deadlock due to tag
allocation. In my case, the tag was hold by a keep alive request
waiting inside admin_q, as we quiesced admin_q while reset ctrl, so the
request maked as idle and will not process before reset success. As
fabric_q shares tagset with admin_q, while reconnect remote target, we
need a tag for connect command, but the only one reserved tag was held
by keep alive command which waiting inside admin_q. As a result, we
failed to reconnect admin_q forever. In order to fix this issue, I
think we should keep two reserved tags for admin queue.</Note>
    </Notes>
    <CVE>CVE-2024-27435</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 optional feature of PCI MSI called "Multiple Message" allows a
device to use multiple consecutive interrupt vectors.  Unlike for MSI-X,
the setting up of these consecutive vectors needs to happen all in one
go.  In this handling an error path could be taken in different
situations, with or without a particular lock held.  This error path
wrongly releases the lock even when it is not currently held.
</Note>
    </Notes>
    <CVE>CVE-2024-31143</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">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"/>
    </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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </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"/>
    </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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </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: 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ll_temac: platform_get_resource replaced by wrong function

The function platform_get_resource was replaced with
devm_platform_ioremap_resource_byname and is called using 0 as name.

This eventually ends up in platform_get_resource_byname in the call
stack, where it causes a null pointer in strcmp.

	if (type == resource_type(r) &amp;&amp; !strcmp(r-&gt;name, name))

It should have been replaced with devm_platform_ioremap_resource.</Note>
    </Notes>
    <CVE>CVE-2024-35796</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Prevent crash when disable stream

[Why]
Disabling stream encoder invokes a function that no longer exists.

[How]
Check if the function declaration is NULL in disable stream encoder.</Note>
    </Notes>
    <CVE>CVE-2024-35799</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/fpu: Keep xfd_state in sync with MSR_IA32_XFD

Commit 672365477ae8 ("x86/fpu: Update XFD state where required") and
commit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced a
per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in
order to avoid unnecessary writes to the MSR.

On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which
wipes out any stale state. But the per CPU cached xfd value is not
reset, which brings them out of sync.

As a consequence a subsequent xfd_update_state() might fail to update
the MSR which in turn can result in XRSTOR raising a #NM in kernel
space, which crashes the kernel.

To fix this, introduce xfd_set_state() to write xfd_state together
with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.</Note>
    </Notes>
    <CVE>CVE-2024-35801</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Mark target gfn of emulated atomic instruction as dirty

When emulating an atomic access on behalf of the guest, mark the target
gfn dirty if the CMPXCHG by KVM is attempted and doesn't fault.  This
fixes a bug where KVM effectively corrupts guest memory during live
migration by writing to guest memory without informing userspace that the
page is dirty.

Marking the page dirty got unintentionally dropped when KVM's emulated
CMPXCHG was converted to do a user access.  Before that, KVM explicitly
mapped the guest page into kernel memory, and marked the page dirty during
the unmap phase.

Mark the page dirty even if the CMPXCHG fails, as the old data is written
back on failure, i.e. the page is still written.  The value written is
guaranteed to be the same because the operation is atomic, but KVM's ABI
is that all writes are dirty logged regardless of the value written.  And
more importantly, that's what KVM did before the buggy commit.

Huge kudos to the folks on the Cc list (and many others), who did all the
actual work of triaging and debugging.

base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64</Note>
    </Notes>
    <CVE>CVE-2024-35804</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Always disable interrupts when taking cgr_lock

smp_call_function_single disables IRQs when executing the callback. To
prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.
This is already done by qman_update_cgr and qman_delete_cgr; fix the
other lockers.</Note>
    </Notes>
    <CVE>CVE-2024-35806</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-35812</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: core: Avoid negative index with array access

Commit 4d0c8d0aef63 ("mmc: core: Use mrq.sbc in close-ended ffu") assigns
prev_idata = idatas[i - 1], but doesn't check that the iterator i is
greater than zero. Let's fix this by adding a check.</Note>
    </Notes>
    <CVE>CVE-2024-35813</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: amdgpu_ttm_gart_bind set gtt bound flag

Otherwise after the GTT bo is released, the GTT and gart space is freed
but amdgpu_ttm_backend_unbind will not clear the gart page table entry
and leave valid mapping entry pointing to the stale system page. Then
if GPU access the gart address mistakely, it will read undefined value
instead page fault, harder to debug and reproduce the real issue.</Note>
    </Notes>
    <CVE>CVE-2024-35817</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ubifs: Set page uptodate in the correct place

Page cache reads are lockless, so setting the freshly allocated page
uptodate before we've overwritten it with the data it's supposed to have
in it will allow a simultaneous reader to see old data.  Move the call
to SetPageUptodate into ubifs_write_end(), which is after we copied the
new data into the page.</Note>
    </Notes>
    <CVE>CVE-2024-35821</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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:

vt: fix unicode buffer corruption when deleting characters

This is the same issue that was fixed for the VGA text buffer in commit
39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the
buffer"). The cure is also the same i.e. replace memcpy() with memmove()
due to the overlaping buffers.</Note>
    </Notes>
    <CVE>CVE-2024-35823</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: ncm: Fix handling of zero block length packets

While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX
set to 65536, it has been observed that we receive short packets,
which come at interval of 5-10 seconds sometimes and have block
length zero but still contain 1-2 valid datagrams present.

According to the NCM spec:

"If wBlockLength = 0x0000, the block is terminated by a
short packet. In this case, the USB transfer must still
be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If
exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent,
and the size is a multiple of wMaxPacketSize for the
given pipe, then no ZLP shall be sent.

wBlockLength= 0x0000 must be used with extreme care, because
of the possibility that the host and device may get out of
sync, and because of test issues.

wBlockLength = 0x0000 allows the sender to reduce latency by
starting to send a very large NTB, and then shortening it when
the sender discovers that there's not sufficient data to justify
sending a large NTB"

However, there is a potential issue with the current implementation,
as it checks for the occurrence of multiple NTBs in a single
giveback by verifying if the leftover bytes to be processed is zero
or not. If the block length reads zero, we would process the same
NTB infintely because the leftover bytes is never zero and it leads
to a crash. Fix this by bailing out if block length reads zero.</Note>
    </Notes>
    <CVE>CVE-2024-35825</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/lima: fix a memleak in lima_heap_alloc

When lima_vm_map_bo fails, the resources need to be deallocated, or
there will be memleaks.</Note>
    </Notes>
    <CVE>CVE-2024-35829</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fsl-qdma: Fix a memory leak related to the queue command DMA

This dma_alloc_coherent() is undone neither in the remove function, nor in
the error handling path of fsl_qdma_probe().

Switch to the managed version to fix both issues.</Note>
    </Notes>
    <CVE>CVE-2024-35833</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: dbg-tlv: ensure NUL termination

The iwl_fw_ini_debug_info_tlv is used as a string, so we must
ensure the string is terminated correctly before using it.</Note>
    </Notes>
    <CVE>CVE-2024-35845</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

irqchip/gic-v3-its: Prevent double free on error

The error handling path in its_vpe_irq_domain_alloc() causes a double free
when its_vpe_init() fails after successfully allocating at least one
interrupt. This happens because its_vpe_irq_domain_free() frees the
interrupts along with the area bitmap and the vprop_page and
its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the
vprop_page again.

Fix this by unconditionally invoking its_vpe_irq_domain_free() which
handles all cases correctly and by removing the bitmap/vprop_page freeing
from its_vpe_irq_domain_alloc().

[ tglx: Massaged change log ]</Note>
    </Notes>
    <CVE>CVE-2024-35847</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix NULL-deref on non-serdev suspend

Qualcomm ROME controllers can be registered from the Bluetooth line
discipline and in this case the HCI UART serdev pointer is NULL.

Add the missing sanity check to prevent a NULL-pointer dereference when
wakeup() is called for a non-serdev controller during suspend.

Just return true for now to restore the original behaviour and address
the crash with pre-6.2 kernels, which do not have commit e9b3e5b8c657
("Bluetooth: hci_qca: only assign wakeup with serial port support") that
causes the crash to happen already at setup() time.</Note>
    </Notes>
    <CVE>CVE-2024-35851</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash work

The rehash delayed work is rescheduled with a delay if the number of
credits at end of the work is not negative as supposedly it means that
the migration ended. Otherwise, it is rescheduled immediately.

After "mlxsw: spectrum_acl_tcam: Fix possible use-after-free during
rehash" the above is no longer accurate as a non-negative number of
credits is no longer indicative of the migration being done. It can also
happen if the work encountered an error in which case the migration will
resume the next time the work is scheduled.

The significance of the above is that it is possible for the work to be
pending and associated with hints that were allocated when the migration
started. This leads to the hints being leaked [1] when the work is
canceled while pending as part of ACL region dismantle.

Fix by freeing the hints if hints are associated with a work that was
canceled while pending.

Blame the original commit since the reliance on not having a pending
work associated with hints is fragile.

[1]
unreferenced object 0xffff88810e7c3000 (size 256):
  comm "kworker/0:16", pid 176, jiffies 4295460353
  hex dump (first 32 bytes):
    00 30 95 11 81 88 ff ff 61 00 00 00 00 00 00 80  .0......a.......
    00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00  ..a.@...........
  backtrace (crc 2544ddb9):
    [&lt;00000000cf8cfab3&gt;] kmalloc_trace+0x23f/0x2a0
    [&lt;000000004d9a1ad9&gt;] objagg_hints_get+0x42/0x390
    [&lt;000000000b143cf3&gt;] mlxsw_sp_acl_erp_rehash_hints_get+0xca/0x400
    [&lt;0000000059bdb60a&gt;] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160
    [&lt;00000000e81fd734&gt;] process_one_work+0x59c/0xf20
    [&lt;00000000ceee9e81&gt;] worker_thread+0x799/0x12c0
    [&lt;00000000bda6fe39&gt;] kthread+0x246/0x300
    [&lt;0000000070056d23&gt;] ret_from_fork+0x34/0x70
    [&lt;00000000dea2b93e&gt;] ret_from_fork_asm+0x1a/0x30</Note>
    </Notes>
    <CVE>CVE-2024-35852</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash

The rehash delayed work migrates filters from one region to another
according to the number of available credits.

The migrated from region is destroyed at the end of the work if the
number of credits is non-negative as the assumption is that this is
indicative of migration being complete. This assumption is incorrect as
a non-negative number of credits can also be the result of a failed
migration.

The destruction of a region that still has filters referencing it can
result in a use-after-free [1].

Fix by not destroying the region if migration failed.

[1]
BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230
Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858

CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G        W          6.9.0-rc2-custom-00782-gf2275c2157d8 #5
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0xc6/0x120
 print_report+0xce/0x670
 kasan_report+0xd7/0x110
 mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230
 mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70
 mlxsw_sp_acl_atcam_entry_del+0x81/0x210
 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50
 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300
 process_one_work+0x8eb/0x19b0
 worker_thread+0x6c9/0xf70
 kthread+0x2c9/0x3b0
 ret_from_fork+0x4d/0x80
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;

Allocated by task 174:
 kasan_save_stack+0x33/0x60
 kasan_save_track+0x14/0x30
 __kasan_kmalloc+0x8f/0xa0
 __kmalloc+0x19c/0x360
 mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0
 mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300
 process_one_work+0x8eb/0x19b0
 worker_thread+0x6c9/0xf70
 kthread+0x2c9/0x3b0
 ret_from_fork+0x4d/0x80
 ret_from_fork_asm+0x1a/0x30

Freed by task 7:
 kasan_save_stack+0x33/0x60
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3b/0x60
 poison_slab_object+0x102/0x170
 __kasan_slab_free+0x14/0x30
 kfree+0xc1/0x290
 mlxsw_sp_acl_tcam_region_destroy+0x272/0x310
 mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300
 process_one_work+0x8eb/0x19b0
 worker_thread+0x6c9/0xf70
 kthread+0x2c9/0x3b0
 ret_from_fork+0x4d/0x80
 ret_from_fork_asm+0x1a/0x30</Note>
    </Notes>
    <CVE>CVE-2024-35854</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: support deferring bpf_link dealloc to after RCU grace period

BPF link for some program types is passed as a "context" which can be
used by those BPF programs to look up additional information. E.g., for
multi-kprobes and multi-uprobes, link is used to fetch BPF cookie values.

Because of this runtime dependency, when bpf_link refcnt drops to zero
there could still be active BPF programs running accessing link data.

This patch adds generic support to defer bpf_link dealloc callback to
after RCU GP, if requested. This is done by exposing two different
deallocation callbacks, one synchronous and one deferred. If deferred
one is provided, bpf_link_free() will schedule dealloc_deferred()
callback to happen after RCU GP.

BPF is using two flavors of RCU: "classic" non-sleepable one and RCU
tasks trace one. The latter is used when sleepable BPF programs are
used. bpf_link_free() accommodates that by checking underlying BPF
program's sleepable flag, and goes either through normal RCU GP only for
non-sleepable, or through RCU tasks trace GP *and* then normal RCU GP
(taking into account rcu_trace_implies_rcu_gp() optimization), if BPF
program is sleepable.

We use this for multi-kprobe and multi-uprobe links, which dereference
link during program run. We also preventively switch raw_tp link to use
deferred dealloc callback, as upcoming changes in bpf-next tree expose
raw_tp link data (specifically, cookie value) to BPF program at runtime
as well.</Note>
    </Notes>
    <CVE>CVE-2024-35860</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_signal_cifsd_for_reconnect()

Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF.</Note>
    </Notes>
    <CVE>CVE-2024-35861</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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"/>
    </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"/>
    </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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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_dump_full_key()

Skip sessions that are being teared down (status == SES_EXITING) to
avoid UAF.</Note>
    </Notes>
    <CVE>CVE-2024-35866</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: guarantee refcounted children from parent session

Avoid potential use-after-free bugs when walking DFS referrals,
mounting and performing DFS failover by ensuring that all children
from parent @tcon-&gt;ses are also refcounted.  They're all needed across
the entire DFS mount.  Get rid of @tcon-&gt;dfs_ses_list while we're at
it, too.</Note>
    </Notes>
    <CVE>CVE-2024-35869</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mm/secretmem: fix GUP-fast succeeding on secretmem folios

folio_is_secretmem() currently relies on secretmem folios being LRU
folios, to save some cycles.

However, folios might reside in a folio batch without the LRU flag set, or
temporarily have their LRU flag cleared.  Consequently, the LRU flag is
unreliable for this purpose.

In particular, this is the case when secretmem_fault() allocates a fresh
page and calls filemap_add_folio()-&gt;folio_add_lru().  The folio might be
added to the per-cpu folio batch and won't get the LRU flag set until the
batch was drained using e.g., lru_add_drain().

Consequently, folio_is_secretmem() might not detect secretmem folios and
GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel
when we would later try reading/writing to the folio, because the folio
has been unmapped from the directmap.

Fix it by removing that unreliable check.</Note>
    </Notes>
    <CVE>CVE-2024-35872</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/coco: Require seeding RNG with RDRAND on CoCo systems

There are few uses of CoCo that don't rely on working cryptography and
hence a working RNG. Unfortunately, the CoCo threat model means that the
VM host cannot be trusted and may actively work against guests to
extract secrets or manipulate computation. Since a malicious host can
modify or observe nearly all inputs to guests, the only remaining source
of entropy for CoCo guests is RDRAND.

If RDRAND is broken -- due to CPU hardware fault -- the RNG as a whole
is meant to gracefully continue on gathering entropy from other sources,
but since there aren't other sources on CoCo, this is catastrophic.
This is mostly a concern at boot time when initially seeding the RNG, as
after that the consequences of a broken RDRAND are much more
theoretical.

So, try at boot to seed the RNG using 256 bits of RDRAND output. If this
fails, panic(). This will also trigger if the system is booted without
RDRAND, as RDRAND is essential for a safe CoCo boot.

Add this deliberately to be "just a CoCo x86 driver feature" and not
part of the RNG itself. Many device drivers and platforms have some
desire to contribute something to the RNG, and add_device_randomness()
is specifically meant for this purpose.

Any driver can call it with seed data of any quality, or even garbage
quality, and it can only possibly make the quality of the RNG better or
have no effect, but can never make it worse.

Rather than trying to build something into the core of the RNG, consider
the particular CoCo issue just a CoCo issue, and therefore separate it
all out into driver (well, arch/platform) code.

  [ bp: Massage commit message. ]</Note>
    </Notes>
    <CVE>CVE-2024-35875</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: dynamic: Synchronize of_changeset_destroy() with the devlink removals

In the following sequence:
  1) of_platform_depopulate()
  2) of_overlay_remove()

During the step 1, devices are destroyed and devlinks are removed.
During the step 2, OF nodes are destroyed but
__of_changeset_entry_destroy() can raise warnings related to missing
of_node_put():
  ERROR: memory leak, expected refcount 1 instead of 2 ...

Indeed, during the devlink removals performed at step 1, the removal
itself releasing the device (and the attached of_node) is done by a job
queued in a workqueue and so, it is done asynchronously with respect to
function calls.
When the warning is present, of_node_put() will be called but wrongly
too late from the workqueue job.

In order to be sure that any ongoing devlink removals are done before
the of_node destruction, synchronize the of_changeset_destroy() with the
devlink removals.</Note>
    </Notes>
    <CVE>CVE-2024-35879</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mlxbf_gige: stop interface during shutdown

The mlxbf_gige driver intermittantly encounters a NULL pointer
exception while the system is shutting down via "reboot" command.
The mlxbf_driver will experience an exception right after executing
its shutdown() method.  One example of this exception is:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070
Mem abort info:
  ESR = 0x0000000096000004
  EC = 0x25: DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
  FSC = 0x04: level 0 translation fault
Data abort info:
  ISV = 0, ISS = 0x00000004
  CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=000000011d373000
[0000000000000070] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 96000004 [#1] SMP
CPU: 0 PID: 13 Comm: ksoftirqd/0 Tainted: G S         OE     5.15.0-bf.6.gef6992a #1
Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 Apr 21 2023
pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]
lr : mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]
sp : ffff8000080d3c10
x29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58
x26: ffff0000814e7340 x25: ffff331cd1a05000 x24: ffffcce72c4ea008
x23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128
x20: 0000000000000000 x19: ffff0000814e4a80 x18: ffffffffffffffff
x17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7
x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101
x11: 7f7f7f7f7f7f7f7f x10: c2ac898b17576267 x9 : ffffcce720fa5404
x8 : ffff000080812138 x7 : 0000000000002e9a x6 : 0000000000000080
x5 : ffff00008de3b000 x4 : 0000000000000000 x3 : 0000000000000001
x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
 mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]
 mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]
 __napi_poll+0x40/0x1c8
 net_rx_action+0x314/0x3a0
 __do_softirq+0x128/0x334
 run_ksoftirqd+0x54/0x6c
 smpboot_thread_fn+0x14c/0x190
 kthread+0x10c/0x110
 ret_from_fork+0x10/0x20
Code: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002)
---[ end trace 7cc3941aa0d8e6a4 ]---
Kernel panic - not syncing: Oops: Fatal exception in interrupt
Kernel Offset: 0x4ce722520000 from 0xffff800008000000
PHYS_OFFSET: 0x80000000
CPU features: 0x000005c1,a3330e5a
Memory Limit: none
---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---

During system shutdown, the mlxbf_gige driver's shutdown() is always executed.
However, the driver's stop() method will only execute if networking interface
configuration logic within the Linux distribution has been setup to do so.

If shutdown() executes but stop() does not execute, NAPI remains enabled
and this can lead to an exception if NAPI is scheduled while the hardware
interface has only been partially deinitialized.

The networking interface managed by the mlxbf_gige driver must be properly
stopped during system shutdown so that IFF_UP is cleared, the hardware
interface is put into a clean state, and NAPI is fully deinitialized.</Note>
    </Notes>
    <CVE>CVE-2024-35885</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: mana: Fix Rx DMA datasize and skb_over_panic

mana_get_rxbuf_cfg() aligns the RX buffer's DMA datasize to be
multiple of 64. So a packet slightly bigger than mtu+14, say 1536,
can be received and cause skb_over_panic.

Sample dmesg:
[ 5325.237162] skbuff: skb_over_panic: text:ffffffffc043277a len:1536 put:1536 head:ff1100018b517000 data:ff1100018b517100 tail:0x700 end:0x6ea dev:&lt;NULL&gt;
[ 5325.243689] ------------[ cut here ]------------
[ 5325.245748] kernel BUG at net/core/skbuff.c:192!
[ 5325.247838] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[ 5325.258374] RIP: 0010:skb_panic+0x4f/0x60
[ 5325.302941] Call Trace:
[ 5325.304389]  &lt;IRQ&gt;
[ 5325.315794]  ? skb_panic+0x4f/0x60
[ 5325.317457]  ? asm_exc_invalid_op+0x1f/0x30
[ 5325.319490]  ? skb_panic+0x4f/0x60
[ 5325.321161]  skb_put+0x4e/0x50
[ 5325.322670]  mana_poll+0x6fa/0xb50 [mana]
[ 5325.324578]  __napi_poll+0x33/0x1e0
[ 5325.326328]  net_rx_action+0x12e/0x280

As discussed internally, this alignment is not necessary. To fix
this bug, remove it from the code. So oversized packets will be
marked as CQE_RX_TRUNCATED by NIC, and dropped.</Note>
    </Notes>
    <CVE>CVE-2024-35901</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: avoid dereference of garbage after mount failure

In case kern_mount() fails and returns an error pointer return in the
error branch instead of continuing and dereferencing the error pointer.

While on it drop the never read static variable selinuxfs_mount.</Note>
    </Notes>
    <CVE>CVE-2024-35904</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Protect against int overflow for stack access size

This patch re-introduces protection against the size of access to stack
memory being negative; the access size can appear negative as a result
of overflowing its signed int representation. This should not actually
happen, as there are other protections along the way, but we should
protect against it anyway. One code path was missing such protections
(fixed in the previous patch in the series), causing out-of-bounds array
accesses in check_stack_range_initialized(). This patch causes the
verification of a program with such a non-sensical access size to fail.

This check used to exist in a more indirect way, but was inadvertendly
removed in a833a17aeac7.</Note>
    </Notes>
    <CVE>CVE-2024-35905</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mlxbf_gige: call request_irq() after NAPI initialized

The mlxbf_gige driver encounters a NULL pointer exception in
mlxbf_gige_open() when kdump is enabled.  The sequence to reproduce
the exception is as follows:
a) enable kdump
b) trigger kdump via "echo c &gt; /proc/sysrq-trigger"
c) kdump kernel executes
d) kdump kernel loads mlxbf_gige module
e) the mlxbf_gige module runs its open() as the
   the "oob_net0" interface is brought up
f) mlxbf_gige module will experience an exception
   during its open(), something like:

     Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
     Mem abort info:
       ESR = 0x0000000086000004
       EC = 0x21: IABT (current EL), IL = 32 bits
       SET = 0, FnV = 0
       EA = 0, S1PTW = 0
       FSC = 0x04: level 0 translation fault
     user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e29a4000
     [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
     Internal error: Oops: 0000000086000004 [#1] SMP
     CPU: 0 PID: 812 Comm: NetworkManager Tainted: G           OE     5.15.0-1035-bluefield #37-Ubuntu
     Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.6.0.13024 Jan 19 2024
     pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : 0x0
     lr : __napi_poll+0x40/0x230
     sp : ffff800008003e00
     x29: ffff800008003e00 x28: 0000000000000000 x27: 00000000ffffffff
     x26: ffff000066027238 x25: ffff00007cedec00 x24: ffff800008003ec8
     x23: 000000000000012c x22: ffff800008003eb7 x21: 0000000000000000
     x20: 0000000000000001 x19: ffff000066027238 x18: 0000000000000000
     x17: ffff578fcb450000 x16: ffffa870b083c7c0 x15: 0000aaab010441d0
     x14: 0000000000000001 x13: 00726f7272655f65 x12: 6769675f6662786c
     x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa870b0842398
     x8 : 0000000000000004 x7 : fe5a48b9069706ea x6 : 17fdb11fc84ae0d2
     x5 : d94a82549d594f35 x4 : 0000000000000000 x3 : 0000000000400100
     x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000066027238
     Call trace:
      0x0
      net_rx_action+0x178/0x360
      __do_softirq+0x15c/0x428
      __irq_exit_rcu+0xac/0xec
      irq_exit+0x18/0x2c
      handle_domain_irq+0x6c/0xa0
      gic_handle_irq+0xec/0x1b0
      call_on_irq_stack+0x20/0x2c
      do_interrupt_handler+0x5c/0x70
      el1_interrupt+0x30/0x50
      el1h_64_irq_handler+0x18/0x2c
      el1h_64_irq+0x7c/0x80
      __setup_irq+0x4c0/0x950
      request_threaded_irq+0xf4/0x1bc
      mlxbf_gige_request_irqs+0x68/0x110 [mlxbf_gige]
      mlxbf_gige_open+0x5c/0x170 [mlxbf_gige]
      __dev_open+0x100/0x220
      __dev_change_flags+0x16c/0x1f0
      dev_change_flags+0x2c/0x70
      do_setlink+0x220/0xa40
      __rtnl_newlink+0x56c/0x8a0
      rtnl_newlink+0x58/0x84
      rtnetlink_rcv_msg+0x138/0x3c4
      netlink_rcv_skb+0x64/0x130
      rtnetlink_rcv+0x20/0x30
      netlink_unicast+0x2ec/0x360
      netlink_sendmsg+0x278/0x490
      __sock_sendmsg+0x5c/0x6c
      ____sys_sendmsg+0x290/0x2d4
      ___sys_sendmsg+0x84/0xd0
      __sys_sendmsg+0x70/0xd0
      __arm64_sys_sendmsg+0x2c/0x40
      invoke_syscall+0x78/0x100
      el0_svc_common.constprop.0+0x54/0x184
      do_el0_svc+0x30/0xac
      el0_svc+0x48/0x160
      el0t_64_sync_handler+0xa4/0x12c
      el0t_64_sync+0x1a4/0x1a8
     Code: bad PC value
     ---[ end trace 7d1c3f3bf9d81885 ]---
     Kernel panic - not syncing: Oops: Fatal exception in interrupt
     Kernel Offset: 0x2870a7a00000 from 0xffff800008000000
     PHYS_OFFSET: 0x80000000
     CPU features: 0x0,000005c1,a3332a5a
     Memory Limit: none
     ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---

The exception happens because there is a pending RX interrupt before the
call to request_irq(RX IRQ) executes.  Then, the RX IRQ handler fires
immediately after this request_irq() completes. The
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-35907</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: rfi: fix potential response leaks

If the rx payload length check fails, or if kmemdup() fails,
we still need to free the command response. Fix that.</Note>
    </Notes>
    <CVE>CVE-2024-35912</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet

syzbot reported the following uninit-value access issue [1][2]:

nci_rx_work() parses and processes received packet. When the payload
length is zero, each message type handler reads uninitialized payload
and KMSAN detects this issue. The receipt of a packet with a zero-size
payload is considered unexpected, and therefore, such packets should be
silently discarded.

This patch resolved this issue by checking payload size before calling
each message type handler codes.</Note>
    </Notes>
    <CVE>CVE-2024-35915</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: typec: ucsi: Limit read size on v1.2

Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was
increased from 16 to 256. In order to avoid overflowing reads for older
systems, add a mechanism to use the read UCSI version to truncate read
sizes on UCSI v1.2.</Note>
    </Notes>
    <CVE>CVE-2024-35924</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btintel: Fix null ptr deref in btintel_read_version

If hci_cmd_sync_complete() is triggered and skb is NULL, then
hdev-&gt;req_skb is NULL, which will cause this issue.</Note>
    </Notes>
    <CVE>CVE-2024-35933</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: decrease MHI channel buffer length to 8KB

Currently buf_len field of ath11k_mhi_config_qca6390 is assigned
with 0, making MHI use a default size, 64KB, to allocate channel
buffers. This is likely to fail in some scenarios where system
memory is highly fragmented and memory compaction or reclaim is
not allowed.

There is a fail report which is caused by it:
kworker/u32:45: page allocation failure: order:4, mode:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0
CPU: 0 PID: 19318 Comm: kworker/u32:45 Not tainted 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (unreleased) 493b6d5b382c603654d7a81fc3c144d59a1dfceb
Workqueue: events_unbound async_run_entry_fn
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x47/0x60
 warn_alloc+0x13a/0x1b0
 ? srso_alias_return_thunk+0x5/0xfbef5
 ? __alloc_pages_direct_compact+0xab/0x210
 __alloc_pages_slowpath.constprop.0+0xd3e/0xda0
 __alloc_pages+0x32d/0x350
 ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 __kmalloc_large_node+0x72/0x110
 __kmalloc+0x37c/0x480
 ? mhi_map_single_no_bb+0x77/0xf0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 __mhi_prepare_for_transfer+0x44/0x80 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 ? __pfx_____mhi_prepare_for_transfer+0x10/0x10 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 device_for_each_child+0x5c/0xa0
 ? __pfx_pci_pm_resume+0x10/0x10
 ath11k_core_resume+0x65/0x100 [ath11k a5094e22d7223135c40d93c8f5321cf09fd85e4e]
 ? srso_alias_return_thunk+0x5/0xfbef5
 ath11k_pci_pm_resume+0x32/0x60 [ath11k_pci 830b7bfc3ea80ebef32e563cafe2cb55e9cc73ec]
 ? srso_alias_return_thunk+0x5/0xfbef5
 dpm_run_callback+0x8c/0x1e0
 device_resume+0x104/0x340
 ? __pfx_dpm_watchdog_handler+0x10/0x10
 async_resume+0x1d/0x30
 async_run_entry_fn+0x32/0x120
 process_one_work+0x168/0x330
 worker_thread+0x2f5/0x410
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe8/0x120
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x34/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
 &lt;/TASK&gt;

Actually those buffers are used only by QMI target -&gt; host communication.
And for WCN6855 and QCA6390, the largest packet size for that is less
than 6KB. So change buf_len field to 8KB, which results in order 1
allocation if page size is 4KB. In this way, we can at least save some
memory, and as well as decrease the possibility of allocation failure
in those scenarios.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30</Note>
    </Notes>
    <CVE>CVE-2024-35938</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

dma-direct: Leak pages on dma_set_decrypted() failure

On TDX it is possible for the untrusted host to cause
set_memory_encrypted() or set_memory_decrypted() to fail such that an
error is returned and the resulting memory is shared. Callers need to
take care to handle these errors to avoid returning decrypted (shared)
memory to the page allocator, which could lead to functional or security
issues.

DMA could free decrypted/shared pages if dma_set_decrypted() fails. This
should be a rare case. Just leak the pages in this case instead of
freeing them.</Note>
    </Notes>
    <CVE>CVE-2024-35939</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pstore/zone: Add a null pointer check to the psz_kmsg_read

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-35940</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pmdomain: ti: Add a null pointer check to the omap_prm_domain_init

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-35943</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()

Subject: [PATCH] drm/panfrost: Fix the error path in
 panfrost_mmu_map_fault_addr()

If some the pages or sgt allocation failed, we shouldn't release the
pages ref we got earlier, otherwise we will end up with unbalanced
get/put_pages() calls. We should instead leave everything in place
and let the BO release function deal with extra cleanup when the object
is destroyed, or let the fault handler try again next time it's called.</Note>
    </Notes>
    <CVE>CVE-2024-35951</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/ast: Fix soft lockup

There is a while-loop in ast_dp_set_on_off() that could lead to
infinite-loop. This is because the register, VGACRI-Dx, checked in
this API is a scratch register actually controlled by a MCU, named
DPMCU, in BMC.

These scratch registers are protected by scu-lock. If suc-lock is not
off, DPMCU can not update these registers and then host will have soft
lockup due to never updated status.

DPMCU is used to control DP and relative registers to handshake with
host's VGA driver. Even the most time-consuming task, DP's link
training, is less than 100ms. 200ms should be enough.</Note>
    </Notes>
    <CVE>CVE-2024-35952</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 mlx5e_priv_init() cleanup flow

When mlx5e_priv_init() fails, the cleanup flow calls mlx5e_selq_cleanup which
calls mlx5e_selq_apply() that assures that the `priv-&gt;state_lock` is held using
lockdep_is_held().

Acquire the state_lock in mlx5e_selq_cleanup().

Kernel log:
=============================
WARNING: suspicious RCU usage
6.8.0-rc3_net_next_841a9b5 #1 Not tainted
-----------------------------
drivers/net/ethernet/mellanox/mlx5/core/en/selq.c:124 suspicious rcu_dereference_protected() usage!

other info that might help us debug this:

rcu_scheduler_active = 2, debug_locks = 1
2 locks held by systemd-modules/293:
 #0: ffffffffa05067b0 (devices_rwsem){++++}-{3:3}, at: ib_register_client+0x109/0x1b0 [ib_core]
 #1: ffff8881096c65c0 (&amp;device-&gt;client_data_rwsem){++++}-{3:3}, at: add_client_context+0x104/0x1c0 [ib_core]

stack backtrace:
CPU: 4 PID: 293 Comm: systemd-modules Not tainted 6.8.0-rc3_net_next_841a9b5 #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+0x8a/0xa0
 lockdep_rcu_suspicious+0x154/0x1a0
 mlx5e_selq_apply+0x94/0xa0 [mlx5_core]
 mlx5e_selq_cleanup+0x3a/0x60 [mlx5_core]
 mlx5e_priv_init+0x2be/0x2f0 [mlx5_core]
 mlx5_rdma_setup_rn+0x7c/0x1a0 [mlx5_core]
 rdma_init_netdev+0x4e/0x80 [ib_core]
 ? mlx5_rdma_netdev_free+0x70/0x70 [mlx5_core]
 ipoib_intf_init+0x64/0x550 [ib_ipoib]
 ipoib_intf_alloc+0x4e/0xc0 [ib_ipoib]
 ipoib_add_one+0xb0/0x360 [ib_ipoib]
 add_client_context+0x112/0x1c0 [ib_core]
 ib_register_client+0x166/0x1b0 [ib_core]
 ? 0xffffffffa0573000
 ipoib_init_module+0xeb/0x1a0 [ib_ipoib]
 do_one_initcall+0x61/0x250
 do_init_module+0x8a/0x270
 init_module_from_file+0x8b/0xd0
 idempotent_init_module+0x17d/0x230
 __x64_sys_finit_module+0x61/0xb0
 do_syscall_64+0x71/0x140
 entry_SYSCALL_64_after_hwframe+0x46/0x4e
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-35959</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_sock: Fix not validating setsockopt user input

Check user input length before copying data.</Note>
    </Notes>
    <CVE>CVE-2024-35963</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: ISO: Fix not validating setsockopt user input

Check user input length before copying data.</Note>
    </Notes>
    <CVE>CVE-2024-35964</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix not validating setsockopt user input

Check user input length before copying data.</Note>
    </Notes>
    <CVE>CVE-2024-35965</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: RFCOMM: Fix not validating setsockopt user input

syzbot reported rfcomm_sock_setsockopt_old() is copying data without
checking user input length.

BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset
include/linux/sockptr.h:49 [inline]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr
include/linux/sockptr.h:55 [inline]
BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old
net/bluetooth/rfcomm/sock.c:632 [inline]
BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70
net/bluetooth/rfcomm/sock.c:673
Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064</Note>
    </Notes>
    <CVE>CVE-2024-35966</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: SCO: Fix not validating setsockopt user input

syzbot reported sco_sock_setsockopt() is copying data without
checking user input length.

BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset
include/linux/sockptr.h:49 [inline]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr
include/linux/sockptr.h:55 [inline]
BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90
net/bluetooth/sco.c:893
Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578</Note>
    </Notes>
    <CVE>CVE-2024-35967</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix header validation in geneve[6]_xmit_skb

syzbot is able to trigger an uninit-value in geneve_xmit() [1]

Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())
uses skb_protocol(skb, true), pskb_inet_may_pull() is only using
skb-&gt;protocol.

If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb-&gt;protocol,
pskb_inet_may_pull() does nothing at all.

If a vlan tag was provided by the caller (af_packet in the syzbot case),
the network header might not point to the correct location, and skb
linear part could be smaller than expected.

Add skb_vlan_inet_prepare() to perform a complete mac validation.

Use this in geneve for the moment, I suspect we need to adopt this
more broadly.

v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest
   - Only call __vlan_get_protocol() for vlan types.

v2,v3 - Addressed Sabrina comments on v1 and v2

[1]

BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]
 BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
  geneve_xmit_skb drivers/net/geneve.c:910 [inline]
  geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
  __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
  netdev_start_xmit include/linux/netdevice.h:4917 [inline]
  xmit_one net/core/dev.c:3531 [inline]
  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
  __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335
  dev_queue_xmit include/linux/netdevice.h:3091 [inline]
  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
  packet_snd net/packet/af_packet.c:3081 [inline]
  packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:745
  __sys_sendto+0x685/0x830 net/socket.c:2191
  __do_sys_sendto net/socket.c:2203 [inline]
  __se_sys_sendto net/socket.c:2199 [inline]
  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

Uninit was created at:
  slab_post_alloc_hook mm/slub.c:3804 [inline]
  slab_alloc_node mm/slub.c:3845 [inline]
  kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577
  __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668
  alloc_skb include/linux/skbuff.h:1318 [inline]
  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
  packet_alloc_skb net/packet/af_packet.c:2930 [inline]
  packet_snd net/packet/af_packet.c:3024 [inline]
  packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:745
  __sys_sendto+0x685/0x830 net/socket.c:2191
  __do_sys_sendto net/socket.c:2203 [inline]
  __se_sys_sendto net/socket.c:2199 [inline]
  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75

CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024</Note>
    </Notes>
    <CVE>CVE-2024-35973</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Fix memory leak in hci_req_sync_complete()

In 'hci_req_sync_complete()', always free the previous sync
request state before assigning reference to a new one.</Note>
    </Notes>
    <CVE>CVE-2024-35978</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: idxd: Fix oops during rmmod on single-CPU platforms

During the removal of the idxd driver, registered offline callback is
invoked as part of the clean up process. However, on systems with only
one CPU online, no valid target is available to migrate the
perf context, resulting in a kernel oops:

    BUG: unable to handle page fault for address: 000000000002a2b8
    #PF: supervisor write access in kernel mode
    #PF: error_code(0x0002) - not-present page
    PGD 1470e1067 P4D 0
    Oops: 0002 [#1] PREEMPT SMP NOPTI
    CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57
    Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023
    RIP: 0010:mutex_lock+0x2e/0x50
    ...
    Call Trace:
    &lt;TASK&gt;
    __die+0x24/0x70
    page_fault_oops+0x82/0x160
    do_user_addr_fault+0x65/0x6b0
    __pfx___rdmsr_safe_on_cpu+0x10/0x10
    exc_page_fault+0x7d/0x170
    asm_exc_page_fault+0x26/0x30
    mutex_lock+0x2e/0x50
    mutex_lock+0x1e/0x50
    perf_pmu_migrate_context+0x87/0x1f0
    perf_event_cpu_offline+0x76/0x90 [idxd]
    cpuhp_invoke_callback+0xa2/0x4f0
    __pfx_perf_event_cpu_offline+0x10/0x10 [idxd]
    cpuhp_thread_fun+0x98/0x150
    smpboot_thread_fn+0x27/0x260
    smpboot_thread_fn+0x1af/0x260
    __pfx_smpboot_thread_fn+0x10/0x10
    kthread+0x103/0x140
    __pfx_kthread+0x10/0x10
    ret_from_fork+0x31/0x50
    __pfx_kthread+0x10/0x10
    ret_from_fork_asm+0x1b/0x30
    &lt;TASK&gt;

Fix the issue by preventing the migration of the perf context to an
invalid target.</Note>
    </Notes>
    <CVE>CVE-2024-35989</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: xilinx_dpdma: Fix locking

There are several places where either chan-&gt;lock or chan-&gt;vchan.lock was
not held. Add appropriate locking. This fixes lockdep warnings like

[   31.077578] ------------[ cut here ]------------
[   31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
[   31.077953] Modules linked in:
[   31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98
[   31.078102] Hardware name: xlnx,zynqmp (DT)
[   31.078169] Workqueue: events_unbound deferred_probe_work_func
[   31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
[   31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0
[   31.078550] sp : ffffffc083bb2e10
[   31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168
[   31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480
[   31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000
[   31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000
[   31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[   31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001
[   31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def
[   31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516
[   31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff
[   31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000
[   31.080307] Call trace:
[   31.080340]  xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
[   31.080518]  xilinx_dpdma_issue_pending+0x11c/0x120
[   31.080595]  zynqmp_disp_layer_update+0x180/0x3ac
[   31.080712]  zynqmp_dpsub_plane_atomic_update+0x11c/0x21c
[   31.080825]  drm_atomic_helper_commit_planes+0x20c/0x684
[   31.080951]  drm_atomic_helper_commit_tail+0x5c/0xb0
[   31.081139]  commit_tail+0x234/0x294
[   31.081246]  drm_atomic_helper_commit+0x1f8/0x210
[   31.081363]  drm_atomic_commit+0x100/0x140
[   31.081477]  drm_client_modeset_commit_atomic+0x318/0x384
[   31.081634]  drm_client_modeset_commit_locked+0x8c/0x24c
[   31.081725]  drm_client_modeset_commit+0x34/0x5c
[   31.081812]  __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168
[   31.081899]  drm_fb_helper_set_par+0x50/0x70
[   31.081971]  fbcon_init+0x538/0xc48
[   31.082047]  visual_init+0x16c/0x23c
[   31.082207]  do_bind_con_driver.isra.0+0x2d0/0x634
[   31.082320]  do_take_over_console+0x24c/0x33c
[   31.082429]  do_fbcon_takeover+0xbc/0x1b0
[   31.082503]  fbcon_fb_registered+0x2d0/0x34c
[   31.082663]  register_framebuffer+0x27c/0x38c
[   31.082767]  __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c
[   31.082939]  drm_fb_helper_initial_config+0x50/0x74
[   31.083012]  drm_fbdev_dma_client_hotplug+0xb8/0x108
[   31.083115]  drm_client_register+0xa0/0xf4
[   31.083195]  drm_fbdev_dma_setup+0xb0/0x1cc
[   31.083293]  zynqmp_dpsub_drm_init+0x45c/0x4e0
[   31.083431]  zynqmp_dpsub_probe+0x444/0x5e0
[   31.083616]  platform_probe+0x8c/0x13c
[   31.083713]  really_probe+0x258/0x59c
[   31.083793]  __driver_probe_device+0xc4/0x224
[   31.083878]  driver_probe_device+0x70/0x1c0
[   31.083961]  __device_attach_driver+0x108/0x1e0
[   31.084052]  bus_for_each_drv+0x9c/0x100
[   31.084125]  __device_attach+0x100/0x298
[   31.084207]  device_initial_probe+0x14/0x20
[   31.084292]  bus_probe_device+0xd8/0xdc
[   31.084368]  deferred_probe_work_func+0x11c/0x180
[   31.084451]  process_one_work+0x3ac/0x988
[   31.084643]  worker_thread+0x398/0x694
[   31.084752]  kthread+0x1bc/0x1c0
[   31.084848]  ret_from_fork+0x10/0x20
[   31.084932] irq event stamp: 64549
[   31.084970] hardirqs last  enabled at (64548): [&lt;ffffffc081adf35c&gt;] _raw_spin_unlock_irqrestore+0x80/0x90
[   31.085157]
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-35990</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: missing lock when picking channel

Coverity spotted a place where we should have been holding the
channel lock when accessing the ses channel index.

Addresses-Coverity: 1582039 ("Data race condition (MISSING_LOCK)")</Note>
    </Notes>
    <CVE>CVE-2024-35999</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mlxsw: spectrum_acl_tcam: Fix incorrect list API usage

Both the function that migrates all the chunks within a region and the
function that migrates all the entries within a chunk call
list_first_entry() on the respective lists without checking that the
lists are not empty. This is incorrect usage of the API, which leads to
the following warning [1].

Fix by returning if the lists are empty as there is nothing to migrate
in this case.

[1]
WARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0&gt;
Modules linked in:
CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0
[...]
Call Trace:
 &lt;TASK&gt;
 mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0
 process_one_work+0x151/0x370
 worker_thread+0x2cb/0x3e0
 kthread+0xd0/0x100
 ret_from_fork+0x34/0x50
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-36006</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mlxsw: spectrum_acl_tcam: Fix warning during rehash

As previously explained, the rehash delayed work migrates filters from
one region to another. This is done by iterating over all chunks (all
the filters with the same priority) in the region and in each chunk
iterating over all the filters.

When the work runs out of credits it stores the current chunk and entry
as markers in the per-work context so that it would know where to resume
the migration from the next time the work is scheduled.

Upon error, the chunk marker is reset to NULL, but without resetting the
entry markers despite being relative to it. This can result in migration
being resumed from an entry that does not belong to the chunk being
migrated. In turn, this will eventually lead to a chunk being iterated
over as if it is an entry. Because of how the two structures happen to
be defined, this does not lead to KASAN splats, but to warnings such as
[1].

Fix by creating a helper that resets all the markers and call it from
all the places the currently only reset the chunk marker. For good
measures also call it when starting a completely new rehash. Add a
warning to avoid future cases.

[1]
WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0
Modules linked in:
CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G        W          6.9.0-rc3-custom-00880-g29e61d91b77b #29
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:mlxsw_afk_encode+0x242/0x2f0
[...]
Call Trace:
 &lt;TASK&gt;
 mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0
 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0
 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290
 mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x470
 process_one_work+0x151/0x370
 worker_thread+0x2cb/0x3e0
 kthread+0xd0/0x100
 ret_from_fork+0x34/0x50
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-36007</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: msft: fix slab-use-after-free in msft_do_close()

Tying the msft-&gt;data lifetime to hdev by freeing it in
hci_release_dev() to fix the following case:

[use]
msft_do_close()
  msft = hdev-&gt;msft_data;
  if (!msft)                      ...(1) &lt;- passed.
    return;
  mutex_lock(&amp;msft-&gt;filter_lock); ...(4) &lt;- used after freed.

[free]
msft_unregister()
  msft = hdev-&gt;msft_data;
  hdev-&gt;msft_data = NULL;         ...(2)
  kfree(msft);                    ...(3) &lt;- msft is freed.

==================================================================
BUG: KASAN: slab-use-after-free in __mutex_lock_common
kernel/locking/mutex.c:587 [inline]
BUG: KASAN: slab-use-after-free in __mutex_lock+0x8f/0xc30
kernel/locking/mutex.c:752
Read of size 8 at addr ffff888106cbbca8 by task kworker/u5:2/309</Note>
    </Notes>
    <CVE>CVE-2024-36012</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fixes a random hang in S4 for SMU v13.0.4/11

While doing multiple S4 stress tests, GC/RLC/PMFW get into
an invalid state resulting into hard hangs.

Adding a GFX reset as workaround just before sending the
MP1_UNLOAD message avoids this failure.</Note>
    </Notes>
    <CVE>CVE-2024-36026</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix info leak when fetching fw build id

Add the missing sanity checks and move the 255-byte build-id buffer off
the stack to avoid leaking stack data through debugfs in case the
build-info reply is malformed.</Note>
    </Notes>
    <CVE>CVE-2024-36032</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: typec: tcpm: Check for port partner validity before consuming it

typec_register_partner() does not guarantee partner registration
to always succeed. In the event of failure, port-&gt;partner is set
to the error value or NULL. Given that port-&gt;partner validity is
not checked, this results in the following crash:

Unable to handle kernel NULL pointer dereference at virtual address xx
 pc : run_state_machine+0x1bc8/0x1c08
 lr : run_state_machine+0x1b90/0x1c08
..
 Call trace:
   run_state_machine+0x1bc8/0x1c08
   tcpm_state_machine_work+0x94/0xe4
   kthread_worker_fn+0x118/0x328
   kthread+0x1d0/0x23c
   ret_from_fork+0x10/0x20

To prevent the crash, check for port-&gt;partner validity before
derefencing it in all the call sites.</Note>
    </Notes>
    <CVE>CVE-2024-36893</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 access violation during port device removal

Testing with KASAN and syzkaller revealed a bug in port.c:disable_store():
usb_hub_to_struct_hub() can return NULL if the hub that the port belongs to
is concurrently removed, but the function does not check for this
possibility before dereferencing the returned value.

It turns out that the first dereference is unnecessary, since hub-&gt;intfdev
is the parent of the port device, so it can be changed easily.  Adding a
check for hub == NULL prevents further problems.

The same bug exists in the disable_show() routine, and it can be fixed the
same way.</Note>
    </Notes>
    <CVE>CVE-2024-36896</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Atom Integrated System Info v2_2 for DCN35

New request from KMD/VBIOS in order to support new UMA carveout
model. This fixes a null dereference from accessing
Ctx-&gt;dc_bios-&gt;integrated_info while it was NULL.

DAL parses through the BIOS and extracts the necessary
integrated_info but was missing a case for the new BIOS
version 2.3.</Note>
    </Notes>
    <CVE>CVE-2024-36897</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: 9381/1: kasan: clear stale stack poison

We found below OOB crash:

[   33.452494] ==================================================================
[   33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec
[   33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0
[   33.455515]
[   33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O       6.1.25-mainline #1
[   33.456880] Hardware name: Generic DT based system
[   33.457555]  unwind_backtrace from show_stack+0x18/0x1c
[   33.458326]  show_stack from dump_stack_lvl+0x40/0x4c
[   33.459072]  dump_stack_lvl from print_report+0x158/0x4a4
[   33.459863]  print_report from kasan_report+0x9c/0x148
[   33.460616]  kasan_report from kasan_check_range+0x94/0x1a0
[   33.461424]  kasan_check_range from memset+0x20/0x3c
[   33.462157]  memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec
[   33.463064]  refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c
[   33.464181]  tick_nohz_idle_stop_tick from do_idle+0x264/0x354
[   33.465029]  do_idle from cpu_startup_entry+0x20/0x24
[   33.465769]  cpu_startup_entry from rest_init+0xf0/0xf4
[   33.466528]  rest_init from arch_post_acpi_subsys_init+0x0/0x18
[   33.467397]
[   33.467644] The buggy address belongs to stack of task swapper/0/0
[   33.468493]  and is located at offset 112 in frame:
[   33.469172]  refresh_cpu_vm_stats.constprop.0+0x0/0x2ec
[   33.469917]
[   33.470165] This frame has 2 objects:
[   33.470696]  [32, 76) 'global_zone_diff'
[   33.470729]  [112, 276) 'global_node_diff'
[   33.471294]
[   33.472095] The buggy address belongs to the physical page:
[   33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03
[   33.473944] flags: 0x1000(reserved|zone=0)
[   33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001
[   33.475656] raw: 00000000
[   33.476050] page dumped because: kasan: bad access detected
[   33.476816]
[   33.477061] Memory state around the buggy address:
[   33.477732]  c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   33.478630]  c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
[   33.479526] &gt;c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1
[   33.480415]                                                ^
[   33.481195]  c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3
[   33.482088]  c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
[   33.482978] ==================================================================

We find the root cause of this OOB is that arm does not clear stale stack
poison in the case of cpuidle.

This patch refer to arch/arm64/kernel/sleep.S to resolve this issue.

From cited commit [1] that explain the problem

Functions which the compiler has instrumented for KASAN place poison on
the stack shadow upon entry and remove this poison prior to returning.

In the case of cpuidle, CPUs exit the kernel a number of levels deep in
C code.  Any instrumented functions on this critical path will leave
portions of the stack shadow poisoned.

If CPUs lose context and return to the kernel via a cold path, we
restore a prior context saved in __cpu_suspend_enter are forgotten, and
we never remove the poison they placed in the stack shadow area by
functions calls between this and the actual exit of the kernel.

Thus, (depending on stackframe layout) subsequent calls to instrumented
functions may hit this stale poison, resulting in (spurious) KASAN
splats to the console.

To avoid this, clear any stale poison from the idle thread for a CPU
prior to bringing a CPU online.

From cited commit [2]

Extend to check for CONFIG_KASAN_STACK

[1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison")
[2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK")</Note>
    </Notes>
    <CVE>CVE-2024-36906</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()

lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the
hbalock.  Thus, lpfc_worker_wake_up() should not be called while holding the
hbalock to avoid potential deadlock.</Note>
    </Notes>
    <CVE>CVE-2024-36924</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/pseries/iommu: LPAR panics during boot up with a frozen PE

At the time of LPAR boot up, partition firmware provides Open Firmware
property ibm,dma-window for the PE. This property is provided on the PCI
bus the PE is attached to.

There are execptions where the partition firmware might not provide this
property for the PE at the time of LPAR boot up. One of the scenario is
where the firmware has frozen the PE due to some error condition. This
PE is frozen for 24 hours or unless the whole system is reinitialized.

Within this time frame, if the LPAR is booted, the frozen PE will be
presented to the LPAR but ibm,dma-window property could be missing.

Today, under these circumstances, the LPAR oopses with NULL pointer
dereference, when configuring the PCI bus the PE is attached to.

  BUG: Kernel NULL pointer dereference on read at 0x000000c8
  Faulting instruction address: 0xc0000000001024c0
  Oops: Kernel access of bad area, sig: 7 [#1]
  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
  Modules linked in:
  Supported: Yes
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.4.0-150600.9-default #1
  Hardware name: IBM,9043-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_023) hv:phyp pSeries
  NIP:  c0000000001024c0 LR: c0000000001024b0 CTR: c000000000102450
  REGS: c0000000037db5c0 TRAP: 0300   Not tainted  (6.4.0-150600.9-default)
  MSR:  8000000002009033 &lt;SF,VEC,EE,ME,IR,DR,RI,LE&gt;  CR: 28000822  XER: 00000000
  CFAR: c00000000010254c DAR: 00000000000000c8 DSISR: 00080000 IRQMASK: 0
  ...
  NIP [c0000000001024c0] pci_dma_bus_setup_pSeriesLP+0x70/0x2a0
  LR [c0000000001024b0] pci_dma_bus_setup_pSeriesLP+0x60/0x2a0
  Call Trace:
    pci_dma_bus_setup_pSeriesLP+0x60/0x2a0 (unreliable)
    pcibios_setup_bus_self+0x1c0/0x370
    __of_scan_bus+0x2f8/0x330
    pcibios_scan_phb+0x280/0x3d0
    pcibios_init+0x88/0x12c
    do_one_initcall+0x60/0x320
    kernel_init_freeable+0x344/0x3e4
    kernel_init+0x34/0x1d0
    ret_from_kernel_user_thread+0x14/0x1c</Note>
    </Notes>
    <CVE>CVE-2024-36926</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 kernel panic after setting hsuid

Symptom:
When the hsuid attribute is set for the first time on an IQD Layer3
device while the corresponding network interface is already UP,
the kernel will try to execute a napi function pointer that is NULL.

Example:
---------------------------------------------------------------------------
[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP
[ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6
nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de
s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod
 qdio ccwgroup pkey zcrypt
[ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1
[ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR)
[ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2)
[ 2057.572748]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3
[ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000
[ 2057.572754]            00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80
[ 2057.572756]            000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8
[ 2057.572758]            00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68
[ 2057.572762] Krnl Code:#0000000000000000: 0000                illegal
                         &gt;0000000000000002: 0000                illegal
                          0000000000000004: 0000                illegal
                          0000000000000006: 0000                illegal
                          0000000000000008: 0000                illegal
                          000000000000000a: 0000                illegal
                          000000000000000c: 0000                illegal
                          000000000000000e: 0000                illegal
[ 2057.572800] Call Trace:
[ 2057.572801] ([&lt;00000000ec639700&gt;] 0xec639700)
[ 2057.572803]  [&lt;00000000913183e2&gt;] net_rx_action+0x2ba/0x398
[ 2057.572809]  [&lt;0000000091515f76&gt;] __do_softirq+0x11e/0x3a0
[ 2057.572813]  [&lt;0000000090ce160c&gt;] do_softirq_own_stack+0x3c/0x58
[ 2057.572817] ([&lt;0000000090d2cbd6&gt;] do_softirq.part.1+0x56/0x60)
[ 2057.572822]  [&lt;0000000090d2cc60&gt;] __local_bh_enable_ip+0x80/0x98
[ 2057.572825]  [&lt;0000000091314706&gt;] __dev_queue_xmit+0x2be/0xd70
[ 2057.572827]  [&lt;000003ff803dd6d6&gt;] afiucv_hs_send+0x24e/0x300 [af_iucv]
[ 2057.572830]  [&lt;000003ff803dd88a&gt;] iucv_send_ctrl+0x102/0x138 [af_iucv]
[ 2057.572833]  [&lt;000003ff803de72a&gt;] iucv_sock_connect+0x37a/0x468 [af_iucv]
[ 2057.572835]  [&lt;00000000912e7e90&gt;] __sys_connect+0xa0/0xd8
[ 2057.572839]  [&lt;00000000912e9580&gt;] sys_socketcall+0x228/0x348
[ 2057.572841]  [&lt;0000000091514e1a&gt;] system_call+0x2a6/0x2c8
[ 2057.572843] Last Breaking-Event-Address:
[ 2057.572844]  [&lt;0000000091317e44&gt;] __napi_poll+0x4c/0x1d8
[ 2057.572846]
[ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt
-------------------------------------------------------------------------------------------

Analysis:
There is one napi structure per out_q: card-&gt;qdio.out_qs[i].napi
The napi.poll functions are set during qeth_open().

Since
commit 1cfef80d4c2b ("s390/qeth: Don't call dev_close/dev_open (DOWN/UP)")
qeth_set_offline()/qeth_set_online() no longer call dev_close()/
dev_open(). So if qeth_free_qdio_queues() cleared
card-&gt;qdio.out_qs[i].napi.poll while the network interface was UP and the
card was offline, they are not set again.

Reproduction:
chzdev -e $devno layer2=0
ip link set dev $network_interface up
echo 0 &gt; /sys/bus/ccw
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-36928</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/cio: Ensure the copied buf is NUL terminated

Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from
userspace to that buffer. Later, we use scanf on this buffer but we don't
ensure that the string is terminated inside the buffer, this can lead to
OOB read when using scanf. Fix this issue by using memdup_user_nul instead.</Note>
    </Notes>
    <CVE>CVE-2024-36931</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix firmware check error path

A recent commit fixed the code that parses the firmware files before
downloading them to the controller but introduced a memory leak in case
the sanity checks ever fail.

Make sure to free the firmware buffer before returning on errors.</Note>
    </Notes>
    <CVE>CVE-2024-36942</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

Reapply "drm/qxl: simplify qxl_fence_wait"

This reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea.

Stephen Rostedt reports:
 "I went to run my tests on my VMs and the tests hung on boot up.
  Unfortunately, the most I ever got out was:

  [   93.607888] Testing event system initcall: OK
  [   93.667730] Running tests on all trace events:
  [   93.669757] Testing all events: OK
  [   95.631064] ------------[ cut here ]------------
  Timed out after 60 seconds"

and further debugging points to a possible circular locking dependency
between the console_owner locking and the worker pool locking.

Reverting the commit allows Steve's VM to boot to completion again.

[ This may obviously result in the "[TTM] Buffer eviction failed"
  messages again, which was the reason for that original revert. But at
  this point this seems preferable to a non-booting system... ]</Note>
    </Notes>
    <CVE>CVE-2024-36944</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

qibfs: fix dentry leak

simple_recursive_removal() drops the pinning references to all positives
in subtree.  For the cases when its argument has been kept alive by
the pinning alone that's exactly the right thing to do, but here
the argument comes from dcache lookup, that needs to be balanced by
explicit dput().

Fucked-up-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;</Note>
    </Notes>
    <CVE>CVE-2024-36947</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Move NPIV's transport unregistration to after resource clean up

There are cases after NPIV deletion where the fabric switch still believes
the NPIV is logged into the fabric.  This occurs when a vport is
unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the
fabric.

Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including
the fabric D_ID, removes the last ndlp reference and frees the ndlp rport
object.  This sometimes causes the race condition where the final DA_ID and
LOGO are skipped from being sent to the fabric switch.

Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID
and LOGO are sent.</Note>
    </Notes>
    <CVE>CVE-2024-36952</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node()

The documentation for device_get_named_child_node() mentions this
important point:

"
The caller is responsible for calling fwnode_handle_put() on the
returned fwnode pointer.
"

Add fwnode_handle_put() to avoid a leaked reference.</Note>
    </Notes>
    <CVE>CVE-2024-36955</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map()

If we fail to allocate propname buffer, we need to drop the reference
count we just took. Because the pinctrl_dt_free_maps() includes the
droping operation, here we call it directly.</Note>
    </Notes>
    <CVE>CVE-2024-36959</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="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"/>
    </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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en"> urllib3 is a user-friendly HTTP client library for Python. When using urllib3's proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected. However, when sending HTTP requests *without* using urllib3's proxy support, it's possible to accidentally configure the `Proxy-Authorization` header even though it won't have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn't treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn't strip the header on cross-origin redirects. Because this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident. Users should use urllib3's proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still decided to strip the header by default in order to further protect users who aren't using the correct approach. We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited: 1. Setting the `Proxy-Authorization` header without using urllib3's built-in proxy support. 2. Not disabling HTTP redirects. 3. Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin. Users are advised to update to either version 1.26.19 or version 2.2.2. Users unable to upgrade may use the `Proxy-Authorization` header with urllib3's `ProxyManager`, disable HTTP redirects using `redirects=False` when sending requests, or not user the `Proxy-Authorization` header as mitigations.</Note>
    </Notes>
    <CVE>CVE-2024-37891</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Moby is an open-source project created by Docker for software containerization. A security vulnerability has been detected in certain versions of Docker Engine, which could allow an attacker to bypass authorization plugins (AuthZ) under specific circumstances. The base likelihood of this being exploited is low.

Using a specially-crafted API request, an Engine API client could make the daemon forward the request or response to an authorization plugin without the body. In certain circumstances, the authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it.

A security issue was discovered In 2018, where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. Although this issue was fixed in Docker Engine v18.09.1 in January 2019, the fix was not carried forward to later major versions, resulting in a regression. Anyone who depends on authorization plugins that introspect the request and/or response body to make access control decisions is potentially impacted.

Docker EE v19.03.x and all versions of Mirantis Container Runtime are not vulnerable.

docker-ce v27.1.1 containes patches to fix the vulnerability. Patches have also been merged into the master, 19.03, 20.0, 23.0, 24.0, 25.0, 26.0, and 26.1 release branches. If one is unable to upgrade immediately, avoid using AuthZ plugins and/or restrict access to the Docker API to trusted parties, following the principle of least privilege.</Note>
    </Notes>
    <CVE>CVE-2024-41110</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>critical</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in the GTK library. Under certain conditions, it is possible for a library to be injected into a GTK application from the current working directory.</Note>
    </Notes>
    <CVE>CVE-2024-6655</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
</cvrfdoc>
