<?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:885-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:885-1</ID>
    </Identification>
    <Status>Interim</Status>
    <Version>1</Version>
    <RevisionHistory>
      <Revision>
        <Number>1</Number>
        <Date>2025-03-13T12:36:49Z</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:885-1 / google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</Note>
    <Note Title="Details" Type="General" Ordinal="2" xml:lang="en">This image update for google/sles-sap-15-sp4-hardened-byos-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

- Version bump to 0.162.3
  * Fix the hexdump log for empty node states
  * catch monitor calls for non-cloned resources and report them as
    unsupported instead of 'command not found'
    (bsc#1218333)
  * fix scope of variable 'site' to be global
    (bsc#1219194)
  * susChkSrv.py - relocate function logTimestamp()
  * update man pages:
    SAPHanaSR.7
    ocf_suse_SAPHana.7
    SAPHanaSR_maintenance_examples.7
    SAPHanaSR.py.7
    SAPHanaSR-showAttr.8

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)

- modify git-47-04210f8df15da0ba4d741cfe1693af06f5978a1d.patch
  drop the stderr redirection for csh (bsc#1221361)
- add git-49-3f8f26123d91f70c644677a323134fc79318c818.patch
  drop sysctl.d/50-default-s390.conf (bsc#1211721)
- add aaa_base-preinstall.patch
  make sure the script does not exit with 1 if a file
  with content is found (bsc#1222547)

- add patch git-48-477bc3c05fcdabf9319e84278a1cba2c12c9ed5a.patch
  home and end button not working from ssh client (bsc#1221407)
- use autosetup in prep stage of specfile

- silence the output in the case of broken symlinks (bsc#1218232)

Package audit-secondary was updated:

- Fix plugin termination when using systemd service units (bsc#1215377)  * add auditd.service-fix-plugin-termination.patch

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)

- autofs-5.1.8-dont-use-initgroups-at-spawn.patch
  Don't use initgroups at spawn (bsc#1214710, bsc#1221181)

Package bind was updated:

- Update to release 9.16.48  Feature Changes:
  * The IP addresses for B.ROOT-SERVERS.NET have been updated to
    170.247.170.2 and 2801:1b8:10::b.
  Security Fixes:
  * Validating DNS messages containing a lot of DNSSEC signatures
    could cause excessive CPU load, leading to a denial-of-service
    condition. This has been fixed. (CVE-2023-50387)
    [bsc#1219823]
  * Preparing an NSEC3 closest encloser proof could cause excessive
    CPU load, leading to a denial-of-service condition. This has
    been fixed. (CVE-2023-50868)
    [bsc#1219826]
  * Parsing DNS messages with many different names could cause
    excessive CPU load. This has been fixed. (CVE-2023-4408)
    [bsc#1219851]
  * Specific queries could cause named to crash with an assertion
    failure when nxdomain-redirect was enabled. This has been
    fixed. (CVE-2023-5517)
    [bsc#1219852]
  * A bad interaction between DNS64 and serve-stale could cause
    named to crash with an assertion failure, when both of these
    features were enabled. This has been fixed. (CVE-2023-5679)
    [bsc#1219853]
  * Query patterns that continuously triggered cache database
    maintenance could cause an excessive amount of memory to be
    allocated, exceeding max-cache-size and potentially leading to
    all available memory on the host running named being exhausted.
    This has been fixed. (CVE-2023-6516)
    [bsc#1219854]
  Removed Features:
  * Support for using AES as the DNS COOKIE algorithm
    (cookie-algorithm aes;) has been deprecated and will be removed
    in a future release. Please use the current default,
    SipHash-2-4, instead.

Package ca-certificates was updated:

- Update to version 2+git20240416.98ae794 (bsc#1221184):  * Use flock to serialize calls (boo#1188500)
  * Make certbundle.run container friendly
  * Create /var/lib/ca-certificates if needed

Package catatonit was updated:

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

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

- Update to version 1.14  + Use '-s' instead of '--no-progress-meter' for curl (bsc#1221757)

- Add version settings to Provides/Obsoletes

- Update to version 1.12 (bsc#1221202)
  + If token access succeeds using IPv4 do not use the IPv6 endpoint
    only use the IPv6 IMDS endpoint if IPv4 access fails.

- Add Provides/Obsoletes for dropped cloud-netconfig-nm
- Install dispatcher script into /etc/NetworkManager/dispatcher.d
  on older distributions
- Add BuildReqires: NetworkManager to avoid owning dispatcher.d
  parent directory

- Update to version 1.11:
  + Revert address metadata lookup in GCE to local lookup (bsc#1219454)
  + Fix hang on warning log messages
  + Check whether getting IPv4 addresses from metadata failed and abort
    if true
  + Only delete policy rules if they exist
  + Skip adding/removing IPv4 ranges if metdata lookup failed
  + Improve error handling and logging in Azure
  + Set SCRIPTDIR when installing netconfig wrapper

- Update to version 1.10:
  + Drop cloud-netconfig-nm sub package and include NM dispatcher
    script in main packages (bsc#1219007)
  + Spec file cleanup

- Update to version 1.9:
  + Drop package dependency on sysconfig-netconfig
  + Improve log level handling
  + Support IPv6 IMDS endpoint in EC2 (bsc#1218069)

Package cloud-regionsrv-client was updated:

- Update to version 10.1.7 (bsc#1220164, bsc#1220165)  + Fix the failover path to a new target update server. At present a new
    server is not found since credential validation fails. We targeted
    the server detected in down condition to verify the credentials instead
    of the replacement server.

Package kernel-default was updated:

- hsr: Prevent use after free in prp_create_tagged_frame()  (CVE-2023-52846 bsc#1225098).
- commit 74c7662

- Update
  patches.suse/powerpc-pseries-iommu-IOMMU-table-is-not-initialized.patch
  (bsc#1220492 ltc#205270 CVE-2024-26745 bsc#1222678).
- commit bb42730

- tcp: Use refcount_inc_not_zero() in tcp_twsk_unique()
  (CVE-2024-36904 bsc#1225732).
- commit 975b193

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

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

- random: treat bootloader trust toggle the same way as cpu
  trust toggle (bsc#1226953).
- commit 9e8060b

- Update
  patches.suse/smb-client-guarantee-refcounted-children-from-parent-session.patch
  (bsc#1224679 CVE-2024-35869).
- commit ed4e9d0

- bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in
  BPF_LINK_CREATE (bsc#1226789 CVE-2024-38564).
- bpf: Add attach_type checks under
  bpf_prog_attach_check_attach_type (bsc#1226789 CVE-2024-38564).
- commit fec2539

- scsi: qedf: Ensure the copied buf is NUL terminated (bsc#1226758
  CVE-2024-38559).
- scsi: bfa: Ensure the copied buf is NUL terminated (bsc#1226786
  CVE-2024-38560).
- commit 45c369f

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

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

- nbd: fix uaf in nbd_open (bsc#1224935 CVE-2023-52837).
- commit fac144b

- of: module: prevent NULL pointer dereference in vsnprintf() (bsc#1226587 CVE-2024-38541)
- commit 0394d90

- of: module: add buffer overflow check in of_modalias() (bsc#1226587 CVE-2024-38541)
- commit e54e996

- net: preserve kabi for struct dst_ops (CVE-2024-36971
  bsc#1226145).
- commit 74d650a

- net: fix __dst_negative_advice() race (CVE-2024-36971
  bsc#1226145).
- commit 6d5c393

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

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

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

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

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

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

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

- blacklist.conf: Add a7fb0423c201 cgroup: Move rcu_head up near the top of cgroup_root
- commit 552377b

- gpiolib: cdev: Fix use after free in lineinfo_changed_notify
  (bsc#1225737 CVE-2024-36899).
- commit 9b295f5

- rpmsg: virtio: Free driver_override when rpmsg_remove()
  (bsc#1224696 CVE-2023-52670).
- commit beb5bc4

- cgroup: preserve KABI of cgroup_root (bsc#1222254).
- commit 240d70b

- cgroup: Add annotation for holding namespace_sem in
  current_cgns_cgroup_from_root() (bsc#1222254).
- cgroup: Eliminate the need for cgroup_mutex in
  proc_cgroup_show() (bsc#1222254).
- cgroup: Make operations on the cgroup root_list RCU safe
  (bsc#1222254).
- cgroup: Remove unnecessary list_empty() (bsc#1222254).
- commit 8c880e4

- wifi: mac80211: check/clear fast rx for non-4addr sta VLAN
  changes (CVE-2024-35789 bsc#1224749).
- commit 2b6904d

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

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

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

- xfs: don't include bnobt blocks when reserving free block pool
  (bsc#1226270).
- commit 1f7ae4f

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

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

- net: vlan: fix underflow for the real_dev refcnt
  (CVE-2021-47555 bsc#1225467).
- commit 345ef84

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

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

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

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

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

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

- Update references
- commit 006ab15

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

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

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

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

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

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

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

- 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

- 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-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/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-btusb-Add-date-evt_skb-is-NULL-check.patch
  (git-fixes bsc#1225595 CVE-2023-52833).
- 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-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-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/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-potential-NULL-ptr-dereference.patch
  (git-fixes bsc#1225121 CVE-2023-52744).
- 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/afs-Fix-corruption-in-reads-at-fpos-2G-4G-from-an-Op.patch
  (stable-5.14.9 bsc#1225160 CVE-2021-47366).
- 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/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/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/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-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-re-dirty-process-of-tree-log-nodes.patch
  (bsc#1197915 bsc#1225410 CVE-2021-47510).
- 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/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-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/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-transfer-buffer-overflows.patch
  (git-fixes stable-5.14.18 bsc#1224914 CVE-2021-47475).
- Update
  patches.suse/cpufreq-schedutil-Use-kobject-release-method-to-free.patch
  (stable-5.14.10 bsc#1225316 CVE-2021-47387).
- 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-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/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
  (git-fixes bsc#1225379 CVE-2021-47550).
- Update
  patches.suse/drm-amd-amdkfd-Fix-kernel-panic-when-reset-failed-an.patch
  (git-fixes bsc#1225510 CVE-2021-47551).
- 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-pm-Update-intermediate-power-state-for-SI.patch
  (stable-5.14.9 bsc#1225153 CVE-2021-47362).
- 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
  (git-fixes stable-5.14.12 bsc#1225353 CVE-2021-47421).
- 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
  (git-fixes stable-5.14.12 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-bridge-lt8912b-Fix-crash-on-bridge-detach.patch
  (git-fixes bsc#1224932 CVE-2023-52856).
- Update
  patches.suse/drm-edid-In-connector_bad_edid-cap-num_of_ext-by-num.patch
  (git-fixes stable-5.14.14 bsc#1225243 CVE-2021-47444).
- Update
  patches.suse/drm-msm-Fix-null-pointer-dereference-on-pointer-edp.patch
  (git-fixes stable-5.14.14 bsc#1225261 CVE-2021-47445).
- Update
  patches.suse/drm-msm-a3xx-fix-error-handling-in-a3xx_gpu_init.patch
  (git-fixes stable-5.14.14 bsc#1225260 CVE-2021-47447).
- Update
  patches.suse/drm-msm-a4xx-fix-error-handling-in-a4xx_gpu_init.patch
  (git-fixes stable-5.14.14 bsc#1225240 CVE-2021-47446).
- Update
  patches.suse/drm-msm-a6xx-Allocate-enough-space-for-GMU-registers.patch
  (git-fixes bsc#1225446 CVE-2021-47535).
- Update
  patches.suse/drm-mxsfb-Fix-NULL-pointer-dereference-crash-on-unlo.patch
  (stable-5.14.15 bsc#1225187 CVE-2021-47471).
- Update
  patches.suse/drm-nouveau-debugfs-fix-file-release-memory-leak.patch
  (git-fixes stable-5.14.12 bsc#1225366 CVE-2021-47423).
- Update
  patches.suse/drm-nouveau-kms-nv50-fix-file-release-memory-leak.patch
  (git-fixes stable-5.14.12 bsc#1225233 CVE-2021-47422).
- 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
  (git-fixes 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-ttm-fix-memleak-in-ttm_transfered_destroy.patch
  (stable-5.14.16 bsc#1225436 CVE-2021-47490).
- Update
  patches.suse/drm-vc4-kms-Add-missing-drm_crtc_commit_put.patch
  (git-fixes CVE-2021-47534).
- Update
  patches.suse/drm-vc4-kms-Clear-the-HVS-FIFO-commit-pointer-once-d.patch
  (git-fixes bsc#1225445 CVE-2021-47533).
- 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-imsttfb-fix-a-resource-leak-in-probe.patch
  (git-fixes bsc#1225031 CVE-2023-52838).
- 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/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
  (git-fixes 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
  (git-fixes 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-mma8452-Fix-trigger-reference-couting.patch
  (git-fixes bsc#1225360 CVE-2021-47500).
- 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/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/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/media-bttv-fix-use-after-free-error-due-to-btv-timeo.patch
  (git-fixes bsc#1225588 CVE-2023-52847).
- 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-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-mmc_spi-fix-error-handling-in-mmc_spi_probe.patch
  (git-fixes bsc#1225483 CVE-2023-52708).
- 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/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-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-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-qlogic-qlcnic-Fix-a-NULL-pointer-dereference-in-.patch
  (git-fixes bsc#1225455 CVE-2021-47542).
- 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-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_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/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/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/padata-Fix-refcnt-handling-in-padata_free_shell.patch
  (git-fixes bsc#1225584 CVE-2023-52854).
- Update patches.suse/phy-mdio-fix-memory-leak.patch (git-fixes
  stable-5.14.12 bsc#1225336 CVE-2021-47416).
- 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/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-smp-do-not-decrement-idle-task-preempt-count.patch
  (stable-5.14.15 bsc#1225255 CVE-2021-47454).
- 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/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-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-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/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-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-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/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/soc-qcom-llcc-Handle-a-second-device-without-data-co.patch
  (git-fixes bsc#1225534 CVE-2023-52871).
- 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/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/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-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-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-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-Fix-NULL-pointer-dereference-in-tcpm_.patch
  (git-fixes bsc#1224944 CVE-2023-52877).
- 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/wifi-ath11k-fix-dfs-radar-event-locking.patch
  (git-fixes bsc#1224947 CVE-2023-52798).
- Update patches.suse/wifi-ath11k-fix-htt-pktlog-locking.patch
  (git-fixes CVE-2023-52800).
- Update
  patches.suse/wifi-mac80211-don-t-return-unset-power-in-ieee80211_.patch
  (git-fixes bsc#1225577 CVE-2023-52832).
- 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/xhci-Fix-command-ring-pointer-corruption-while-abort.patch
  (stable-5.14.14 bsc#1225232 CVE-2021-47434).
- commit c477ba3

- powerpc/pseries/iommu: LPAR panics during boot up with a frozen
  PE (bsc#1222011 ltc#205900 CVE-2024-36926).
- commit db3b1aa

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

- idpf: extend tx watchdog timeout (bsc#1224137).
- commit 64976b7

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

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

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

- 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
  patches.suse/bpf-sockmap-Prevent-lock-inversion-deadlock-in-map-d.patch
  (bsc#1209657 CVE-2023-0160 CVE-2024-35895 bsc#1224511).
- Update
  patches.suse/fs-aio-Check-IOCB_AIO_RW-before-the-struct-aio_kiocb.patch
  (bsc#1222721 CVE-2024-26764 CVE-2024-35815 bsc#1224685).
- Update
  patches.suse/nfsd-Fix-error-cleanup-path-in-nfsd_rename.patch
  (bsc#1221044 CVE-2023-52591 CVE-2024-35914 bsc#1224482).
- Update
  patches.suse/wifi-brcmfmac-Fix-use-after-free-bug-in-brcmf_cfg802.patch
  (CVE-2023-47233 bsc#1216702 CVE-2024-35811 bsc#1224592).
- commit 78f49e4

- Update
  patches.suse/bpf-Guard-stack-limits-against-32bit-overflow.patch
  (git-fixes CVE-2023-52676 bsc#1224730).
- commit bdae745

- Update patches.suse/afs-Fix-page-leak.patch (stable-5.14.9
  CVE-2021-47365 bsc#1224895).
- Update
  patches.suse/drm-amdgpu-Fix-even-more-out-of-bound-writes-from-de.patch
  (bsc#1191949 CVE-2021-42327 stable-5.14.16 CVE-2021-47489
  bsc#1224901).
- Update
  patches.suse/mm-khugepaged-skip-huge-page-collapse-for-special-fi.patch
  (stable-5.14.16 bsc#1193983 CVE-2021-4148 CVE-2021-47491
  bsc#1224900).
- Update
  patches.suse/mm-thp-bail-out-early-in-collapse_file-for-writeback.patch
  (stable-5.14.16 CVE-2021-47492 bsc#1224898).
- commit 9ce4e35

- Update
  patches.suse/drm-nouveau-avoid-a-use-after-free-when-BO-init-fail.patch
  (git-fixes stable-5.14.12 CVE-2020-36788 bsc#1224816).
- commit 92d2a7f

- Update patches.suse/powerpc-powernv-Add-a-null-pointer-check-in-opal_eve.patch
  (bsc#1065729 CVE-2023-52686).
- Update patches.suse/powerpc-powernv-Add-a-null-pointer-check-to-scom_deb.patch
  (bsc#1194869 CVE-2023-52690).
- commit 2a79a5d

- scsi: lpfc: Remove IRQF_ONESHOT flag from threaded IRQ handling
  (bsc#1216124).
- commit 7f04710

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

- filemap: remove use of wait bookmarks (bsc#1224085).
- commit 36d572b

- scsi: qla2xxx: Fix double free of fcport (bsc#1223715
  CVE-2024-26929).
- commit b3136a1

- powerpc/pseries/vio: Don't return ENODEV if node or compatible
  missing (bsc#1220783).
- commit 1f4ad41

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

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

- scsi: qla2xxx: Fix double free of the ha-&amp;gt;vp_map pointer
  (bsc#1223626 CVE-2024-26930).
- commit dba3cc6

- Update
  patches.suse/io_uring-af_unix-disable-sending-io_uring-over-socke.patch
  (bsc#1218447 CVE-2023-6531 CVE-2023-52654 bsc#1224099).
- commit 659f245

- Update
  patches.suse/usb-aqc111-check-packet-for-fixup-for-true-limit.patch
  (bsc#1217169 CVE-2023-52655).
  Added bugzilla ID and CVE
- commit a741c33

- supported.conf: support tcp_dctcp module (jsc#PED-8111)
- commit cca73b5

- Update
  patches.suse/sched-debug-fix-dentry-leak-in-update_sched_domain_d.patch
  (git-fixes CVE-2022-48699 bsc#1223996).
- commit 201a58f

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Call flush_delayed_fput() from nfsd main-loop (bsc#1223380).
- commit 18e662b

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- ext4: regenerate buddy after block freeing failed if under fc
  replay (bsc#1220342 CVE-2024-26601).
- commit c12e20f

- blacklist.conf: Blacklist 83e80a6e3543f3
- commit 62a580e

- fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion
  (bsc#1222721 CVE-2024-26764).
- commit b81d662

- fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via
  libaio (bsc#1222721 CVE-2024-26764).
- commit 6f0ed6e

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

- Update patches.suse/thermal-Fix-NULL-pointer-dereferences-in-of_thermal_.patch (stable-5.14.21 CVE-2021-47202 bsc#1222878)
- commit 9b2ed28

- Update references in
  patches.suse/ocfs2-Avoid-touching-renamed-directory-if-parent-doe.patch
  (bsc#1221044 bsc#1221088 CVE-2023-52591 CVE-2023-52590).
- commit 6a6852e

- Update patches.suse/spi-fix-use-after-free-of-the-add_lock-mutex.patch (git-fixes CVE-2021-47195 bsc#1222832)
- commit e8d48f1

- IB/hfi1: Fix sdma.h tx-&amp;gt;num_descs off-by-one error (bsc#1222726 CVE-2024-26766)
- commit dc4bba0

- scsi: Update max_hw_sectors on rescan (bsc#1216223).
- ibmvfc: make 'max_sectors' a module option (bsc#1216223).
- commit af79c3f

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

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

- Update
  patches.suse/tty-tty_buffer-Fix-the-softlockup-issue-in-flush_to_.patch
  (git-fixes CVE-2021-47185).
- commit de9e1db

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

- Update
  patches.suse/scsi-core-Fix-scsi_mode_sense-buffer-length-handling.patch
  (git-fixes CVE-2021-47182 bsc#1222662).
- commit 641c737

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

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

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

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

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

- Update
  patches.suse/btrfs-do-not-ASSERT-if-the-newly-created-subvolume-a.patch
  (bsc#1219126 CVE-2024-23850 CVE-2024-26727 bsc#1222536).
- commit 9619dfe

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

- fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super
  (bsc#1219264 CVE-2024-0841).
- commit aa8204a

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

- scsi: pm80xx: Avoid leaking tags when processing
  OPC_INB_SET_CONTROLLER_CONFIG command (bsc#1220883
  cve-2023-52500).
- commit fc88013

- Update
  patches.suse/netfilter-nftables-exthdr-fix-4-byte-stack-OOB-write.patch
  (CVE-2023-4881 bsc#1215221 CVE-2023-52628 bsc#1222117).
- commit fd3aabc

- selinux: saner handling of policy reloads (bsc#1222230 bsc#1221044
  CVE-2023-52591).
- commit 66a189d

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

- blacklist.conf: omit reverted sockmap deadlock fix
- commit 397323e

- x86/sev: Harden #VC instruction emulation somewhat (CVE-2024-25742 bsc#1221725).
- commit 2e3eba1

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

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

- README.BRANCH: Remove copy of branch name
- commit 4834fba

- README.BRANCH: Remove copy of branch name
- commit 704bda3

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

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

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

- Update
  patches.suse/HID-intel-ish-hid-ipc-Disable-and-reenable-ACPI-GPE-.patch
  (git-fixes CVE-2023-52519 bsc#1220920).
- Update
  patches.suse/HID-sony-Fix-a-potential-memory-leak-in-sony_probe.patch
  (git-fixes CVE-2023-52529 bsc#1220929).
- Update
  patches.suse/IB-hfi1-Fix-bugs-with-non-PAGE_SIZE-end-multi-iovec-.patch
  (git-fixes CVE-2023-52474 bsc#1220445).
- Update
  patches.suse/RDMA-siw-Fix-connection-failure-handling.patch
  (git-fixes CVE-2023-52513 bsc#1221022).
- Update
  patches.suse/RDMA-srp-Do-not-call-scsi_done-from-srp_abort.patch
  (git-fixes CVE-2023-52515 bsc#1221048).
- Update
  patches.suse/Revert-tty-n_gsm-fix-UAF-in-gsm_cleanup_mux.patch
  (git-fixes CVE-2023-52564 bsc#1220938).
- Update
  patches.suse/bpf-Check-rcu_read_lock_trace_held-before-calling-bp.patch
  (bsc#1220251 CVE-2023-52447 CVE-2023-52621 bsc#1222073).
- Update
  patches.suse/ieee802154-ca8210-Fix-a-potential-UAF-in-ca8210_prob.patch
  (git-fixes CVE-2023-52510 bsc#1220898).
- Update
  patches.suse/net-nfc-llcp-Add-lock-when-modifying-device-list.patch
  (git-fixes CVE-2023-52524 bsc#1220927).
- Update
  patches.suse/net-usb-smsc75xx-Fix-uninit-value-access-in-__smsc75.patch
  (git-fixes CVE-2023-52528 bsc#1220843).
- Update
  patches.suse/nfc-nci-assert-requested-protocol-is-valid.patch
  (git-fixes CVE-2023-52507 bsc#1220833).
- Update
  patches.suse/nilfs2-fix-potential-use-after-free-in-nilfs_gccache.patch
  (git-fixes CVE-2023-52566 bsc#1220940).
- Update
  patches.suse/nvme-fc-Prevent-null-pointer-dereference-in-nvme_fc_.patch
  (bsc#1214842 CVE-2023-52508 bsc#1221015).
- Update
  patches.suse/nvmet-tcp-Fix-a-kernel-panic-when-host-sends-an-inva.patch
  (bsc#1217987 bsc#1217988 bsc#1217989 CVE-2023-6535 CVE-2023-6536
  CVE-2023-6356 CVE-2023-52454 bsc#1220320).
- Update
  patches.suse/platform-x86-think-lmi-Fix-reference-leak.patch
  (git-fixes CVE-2023-52520 bsc#1220921).
- Update
  patches.suse/ravb-Fix-use-after-free-issue-in-ravb_tx_timeout_wor.patch
  (bsc#1212514 CVE-2023-35827 CVE-2023-52509 bsc#1220836).
- Update
  patches.suse/ring-buffer-Do-not-attempt-to-read-past-commit.patch
  (git-fixes CVE-2023-52501 bsc#1220885).
- Update
  patches.suse/serial-8250_port-Check-IRQ-data-before-use.patch
  (git-fixes CVE-2023-52567 bsc#1220839).
- Update
  patches.suse/spi-sun6i-fix-race-between-DMA-RX-transfer-completio.patch
  (git-fixes CVE-2023-52517 bsc#1221055).
- Update
  patches.suse/spi-sun6i-reduce-DMA-RX-transfer-width-to-single-byt.patch
  (git-fixes CVE-2023-52511 bsc#1221012).
- Update
  patches.suse/wifi-mwifiex-Fix-oob-check-condition-in-mwifiex_proc.patch
  (git-fixes CVE-2023-52525 bsc#1220840).
- Update
  patches.suse/x86-alternatives-disable-kasan-in-apply_alternatives.patch
  (git-fixes CVE-2023-52504 bsc#1221553).
- Update
  patches.suse/x86-srso-fix-sbpb-enablement-for-spec_rstack_overflow-off.patch
  (git-fixes CVE-2023-52575 bsc#1220871).
- commit 5f353b0

- Update patches.suse/0001-mmc-moxart_remove-Fix-UAF.patch
  (bsc#1194516 CVE-2022-0487 CVE-2022-48626 bsc#1220366).
- Update
  patches.suse/crypto-qcom-rng-ensure-buffer-for-generate-is-comple.patch
  (git-fixes CVE-2022-48629 bsc#1220989).
- Update
  patches.suse/crypto-qcom-rng-fix-infinite-loop-on-requests-not-mu.patch
  (git-fixes CVE-2022-48630 bsc#1220990).
- commit f8cf886

- Update
  patches.suse/ALSA-hda-intel-sdw-acpi-harden-detection-of-controll.patch
  (git-fixes CVE-2021-46926 bsc#1220478).
- Update
  patches.suse/ALSA-rawmidi-fix-the-uninitalized-user_pversion.patch
  (git-fixes CVE-2021-47096 bsc#1220981).
- Update
  patches.suse/IB-qib-Fix-memory-leak-in-qib_user_sdma_queue_pkts.patch
  (git-fixes CVE-2021-47104 bsc#1220960).
- Update
  patches.suse/Input-elantech-fix-stack-out-of-bound-access-in-elan.patch
  (git-fixes CVE-2021-47097 bsc#1220982).
- Update
  patches.suse/KVM-x86-mmu-Don-t-advance-iterator-after-restart-due.patch
  (git-fixes CVE-2021-47094 bsc#1221551).
- Update patches.suse/NFSD-Fix-READDIR-buffer-overflow.patch
  (git-fixes bsc#1196346 CVE-2021-47107 bsc#1220965).
- Update
  patches.suse/asix-fix-uninit-value-in-asix_mdio_read.patch
  (git-fixes CVE-2021-47101 bsc#1220987).
- Update
  patches.suse/drm-mediatek-hdmi-Perform-NULL-pointer-check-for-mtk.patch
  (git-fixes CVE-2021-47108 bsc#1220986).
- Update
  patches.suse/hwmon-lm90-Prevent-integer-overflow-underflow-in-hys.patch
  (git-fixes CVE-2021-47098 bsc#1220983).
- Update
  patches.suse/ipmi-Fix-UAF-when-uninstall-ipmi_si-and-ipmi_msghand.patch
  (git-fixes CVE-2021-47100 bsc#1220985).
- Update
  patches.suse/ipmi-ssif-initialize-ssif_info-client-early.patch
  (bsc#1193490 CVE-2021-47095 bsc#1220979).
- Update
  patches.suse/mac80211-fix-locking-in-ieee80211_start_ap-error-pat.patch
  (git-fixes CVE-2021-47091 bsc#1220959).
- Update
  patches.suse/net-fix-use-after-free-in-tw_timer_handler.patch
  (bsc#1217195 CVE-2021-46936 bsc#1220439).
- Update
  patches.suse/net-marvell-prestera-fix-incorrect-structure-access.patch
  (git-fixes CVE-2021-47102 bsc#1221009).
- Update
  patches.suse/net-smc-fix-kernel-panic-caused-by-race-of-smc_sock
  (git-fixes CVE-2021-46925 bsc#1220466).
- Update
  patches.suse/nitro_enclaves-Use-get_user_pages_unlocked-call-to-handle-mmap-assert.patch
  (git fixes (mm/gup) CVE-2021-46927 bsc#1220443).
- Update
  patches.suse/platform-x86-intel_pmc_core-fix-memleak-on-registrat.patch
  (git-fixes CVE-2021-47093 bsc#1220978).
- Update patches.suse/sctp-use-call_rcu-to-free-endpoint.patch
  (CVE-2022-20154 bsc#1200599 CVE-2021-46929 bsc#1220482).
- Update patches.suse/tee-optee-Fix-incorrect-page-free-bug.patch
  (jsc#SLE-21844 CVE-2021-47087 bsc#1220954).
- Update
  patches.suse/tun-avoid-double-free-in-tun_free_netdev.patch
  (bsc#1209635 CVE-2022-4744 git-fixes CVE-2021-47082
  bsc#1220969).
- Update
  patches.suse/usb-gadget-f_fs-Clear-ffs_eventfd-in-ffs_data_clear.patch
  (git-fixes CVE-2021-46933 bsc#1220487).
- Update patches.suse/usb-mtu3-fix-list_head-check-warning.patch
  (git-fixes CVE-2021-46930 bsc#1220484).
- Update
  patches.suse/veth-ensure-skb-entering-GRO-are-not-cloned.patch
  (git-fixes CVE-2021-47099 bsc#1220955).
- commit b15f74e

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

- x86/sev: Harden #VC instruction emulation somewhat (CVE-2024-25742 bsc#1221725).
- commit 02ed75a

- dmaengine: fix NULL pointer in channel unregistration function (bsc#1221276 CVE-2023-52492)
- commit f21c2ab

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

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

- fs: introduce lock_rename_child() helper (bsc#1221044
  CVE-2023-52591).
  Refresh patches.suse/fs-Establish-locking-order-for-unrelated-directories.patch
- commit 86376e0

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

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

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

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

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

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

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

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

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

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

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

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

- perf/x86/intel/uncore: Fix NULL pointer dereference issue in
  upi_fill_topology() (bsc#1220237, CVE-2023-52450).
- commit 246b58a

- net/sched: Add module alias for sch_fq_pie (bsc#1210335 CVE-2023-1829).
- commit a69d933

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

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

- Sort upstream patches
- Refresh
  patches.suse/Documentation-hw-vuln-Add-documentation-for-RFDS.patch.
- Refresh
  patches.suse/KVM-x86-Export-RFDS_NO-and-RFDS_CLEAR-to-guests.patch.
- Refresh
  patches.suse/x86-entry-ia32-Ensure-s32-is-sign-extended-to-s64.patch.
- Refresh
  patches.suse/x86-rfds-Mitigate-Register-File-Data-Sampling-RFDS.patch.
- commit f172e12

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

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

- netfs: Only call folio_start_fscache() one time for each folio
  (CVE-2023-52582 bsc#1220878).
- commit dfd082b

- Refresh
  patches.suse/mm-ima-kexec-of-use-memblock_free_late-from-ima_free.patch.
  Fix:
  * Section mismatch (function ima_free_kexec_buffer()) in modpost: vmlinux.o in ima_free_kexec_buffer()
  WARNING: modpost: vmlinux.o(.text+0xac1250): Section mismatch in reference from the function ima_free_kexec_buffer() to the function .init.text:__memblock_free_late()
- commit 5522f01

- powerpc/pseries/iommu: IOMMU table is not initialized for
  kdump over SR-IOV (bsc#1220492 ltc#205270).
- commit 535ea22

- Update
  patches.suse/usb-hub-Guard-against-accesses-to-uninitialized-BOS-.patch
  (bsc#1220790 CVE-2023-52477).
- commit d33bab7

- drm/radeon: check the alloc_workqueue return value in radeon_crtc_init() (bsc#1220413 CVE-2023-52470).
- commit 9d7d799

- drivers/amd/pm: fix a use-after-free in kv_parse_power_table (bsc#1220411 CVE-2023-52469).
- commit f4f0cf4

- group-source-files.pl: Quote filenames (boo#1221077).
  The kernel source now contains a file with a space in the name.
  Add quotes in group-source-files.pl to avoid splitting the filename.
  Also use -print0 / -0 when updating timestamps.
- commit a005e42

- mm,ima,kexec,of: use memblock_free_late from
  ima_free_kexec_buffer (bsc#1220872 CVE-2023-52576).
- commit b1b1c9a

- phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP (bsc#1220340,CVE-2024-26600)
- commit 78e2b4a

- erofs: fix lz4 inplace decompression (CVE-2023-52497
  bsc#1220879).
- commit ddeedf9

- ACPI: extlog: fix NULL pointer dereference check (bsc#1221039
  CVE-2023-52605).
- commit 635c481

- kernel-binary: Fix i386 build
  Fixes: 89eaf4cdce05 (&amp;quot;rpm templates: Move macro definitions below buildrequires&amp;quot;)
- commit f7c6351

- btrfs: remove BUG() after failure to insert delayed dir index
  item (bsc#1220918 CVE-2023-52569).
- btrfs: improve error message after failure to add delayed dir
  index item (bsc#1220918 CVE-2023-52569).
- commit 53e1d2d

- net: nfc: fix races in nfc_llcp_sock_get() and
  nfc_llcp_sock_get_sn() (CVE-2023-52502 bsc#1220831).
- commit 8c33586

- kabi: team: Hide new member header_ops (bsc#1220870
  CVE-2023-52574).
- commit 9f49992

- KVM: s390: fix setting of fpc register (git-fixes bsc#1220392
  bsc#1221040 CVE-2023-52597).
- commit a90b87c

- kernel-binary: vdso: fix filelist for non-usrmerged kernel
  Fixes: a6ad8af207e6 (&amp;quot;rpm templates: Always define usrmerged&amp;quot;)
- commit fb3f221

- bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets
  (bsc#1220926 CVE-2023-52523).
- commit 90d9f50

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

- efivarfs: force RO when remounting if SetVariable is not
  supported (bsc#1220328 CVE-2023-52463).
- commit eed7fb0

- iommu/vt-d: Avoid memory allocation in iommu_suspend()
  (CVE-2023-52559 bsc#1220933).
- commit c9b01ef

- Refresh patches.suse/0001-powerpc-pseries-memhp-Fix-access-beyond-end-of-drmem.patch.
  - update to upstream version
  - rename to same name as SLE15 SP5
- commit 1d2def1

- KVM: x86: Export RFDS_NO and RFDS_CLEAR to guests (bsc#1213456 CVE-2023-28746).
- commit 4aebf4f

- x86/rfds: Mitigate Register File Data Sampling (RFDS)  (bsc#1213456 CVE-2023-28746).
- Update config files.
- commit 29c1c99

- Documentation/hw-vuln: Add documentation for RFDS (bsc#1213456 CVE-2023-28746).
- commit 81de603

- ravb: Fix use-after-free issue in ravb_tx_timeout_work()
  (bsc#1212514 CVE-2023-35827).
- team: fix null-ptr-deref when team device type is changed
  (bsc#1220870 CVE-2023-52574).
- commit 2cc53f5

- Update
  patches.suse/ice-xsk-return-xsk-buffers-back-to-pool-when-cleanin.patch
  (jsc#SLE-18375 bsc#1220961 CVE-2021-47105).
- Update patches.suse/net-mana-Fix-TX-CQE-error-handling.patch
  (bsc#1215986 bsc#1220932 CVE-2023-52532).
- Update
  patches.suse/net-mlx5e-Wrap-the-tx-reporter-dump-callback-to-extr.patch
  (jsc#SLE-19253 bsc#1220486 CVE-2021-46931).
  Added CVE references.
- commit 3e396c2

- Update patches.suse/i2c-validate-user-data-in-compat-ioctl.patch
  (git-fixes bsc#1220469 CVE-2021-46934).
  Add bug and CVE references.
- commit 3a04060

- wifi: mac80211: fix potential key use-after-free (CVE-2023-52530
  bsc#1220930).
- commit 3feca94

- Update patch reference for iwlwifi fix (CVE-2023-52531 bsc#1220931)
- commit bde87cf

- Update patch reference for pinctrl fix (CVE-2021-47083 bsc#1220917)
- commit b608623

- drm/bridge: sii902x: Fix probing race issue (bsc#1220736 CVE-2024-26607).
- commit 70198c4

- Update
  patches.suse/vt-fix-memory-overlapping-when-deleting-chars-in-the.patch
  (git-fixes bsc#1220845 CVE-2022-48627).
- Update
  patches.suse/x86-srso-add-srso-mitigation-for-hygon-processors.patch
  (git-fixes bsc#1220735 CVE-2023-52482).
  Add CVE references.
- commit dcdac38

- mfd: syscon: Fix null pointer dereference in
  of_syscon_register() (bsc#1220433 CVE-2023-52467).
- commit b0262b8

- bpf: Fix re-attachment branch in bpf_tracing_prog_attach
  (bsc#1220254 CVE-2024-26591).
- commit fc948d3

- selftests/bpf: Add test for alu on PTR_TO_FLOW_KEYS (bsc#1220255
  CVE-2024-26589).
- bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS (bsc#1220255
  CVE-2024-26589).
- commit 8a833ce

- iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range (CVE-2023-52484 bsc#1220797).
- commit 2229de3

- tls: fix race between tx work scheduling and socket close
  (CVE-2024-26585 bsc#1220187).
- commit 1306bff

- kabi: restore return type of dst_ops::gc() callback
  (CVE-2023-52340 bsc#1219295).
- ipv6: remove max_size check inline with ipv4 (CVE-2023-52340
  bsc#1219295).
- commit b8eec42

- netfilter: nf_tables: fix 64-bit load issue in
  nft_byteorder_eval() (CVE-2024-0607 bsc#1218915).
- netfilter: nf_tables: fix pointer math issue in
  nft_byteorder_eval() (CVE-2024-0607 bsc#1218915).
- commit e095cd0

- netfilter: nft_set_pipapo: skip inactive elements during set
  walk (CVE-2023-6817 bsc#1218195).
- commit 4032aa7

- tomoyo: fix UAF write bug in tomoyo_write_control() (bsc#1220825
  CVE-2024-26622).
- commit c8e5b38

- doc/README.SUSE: Update information about module support status
  (jsc#PED-5759)
  Following the code change in SLE15-SP6 to have externally supported
  modules no longer taint the kernel, update the respective documentation
  in README.SUSE:
  * Describe that support status can be obtained at runtime for each
  module from /sys/module/$MODULE/supported and for the entire system
  from /sys/kernel/supported. This provides a way how to now check that
  the kernel has any externally supported modules loaded.
  * Remove a mention that externally supported modules taint the kernel,
  but keep the information about bit 16 (X) and add a note that it is
  still tracked per module and can be read from
  /sys/module/$MODULE/taint. This per-module information also appears in
  Oopses.
- commit 9ed8107

- btrfs: fix double free of anonymous device after snapshot
  creation failure (bsc#1219126 CVE-2024-23850).
- commit 257a534

- btrfs: do not ASSERT() if the newly created subvolume already
  got read (bsc#1219126 CVE-2024-23850).
- commit a2ac581

- bpf: Minor cleanup around stack bounds (bsc#1220257
  CVE-2023-52452).
- bpf: Fix accesses to uninit stack slots (bsc#1220257
  CVE-2023-52452).
- bpf: Guard stack limits against 32bit overflow (git-fixes).
- bpf: Fix verification of indirect var-off stack access
  (git-fixes).
- commit 7d03125

- serial: 8250: omap: Don't skip resource freeing if
  pm_runtime_resume_and_get() failed (bsc#1220350 CVE-2023-52457).
- commit c82f528

- serial: imx: fix tx statemachine deadlock (bsc#1220364
  CVE-2023-52456).
- commit cd9f92c

- powerpc/pseries/memhp: Fix access beyond end of drmem array
  (bsc#1220250,CVE-2023-52451).
- commit fdc7254

- Update patch reference for input fix (CVE-2021-46932 bsc#1220444)
- commit e44e0b1

- Update patches.suse/i2c-Fix-a-potential-use-after-free.patch
  (git-fixes bsc#1220409 CVE-2019-25162).
  Add bug and CVE references.
- commit 6df4ebd

- efivarfs: force RO when remounting if SetVariable is not
  supported (bsc#1220328 CVE-2023-52463).
- commit 3cfef52

- btrfs: fix double free of anonymous device after snapshot
  creation failure (bsc#1219126 CVE-2024-23850).
- commit f8ba729

- mtd: Fix gluebi NULL pointer dereference caused by ftl notifier
  (bsc#1220238 CVE-2023-52449).
- commit c132b67

- fs/mount_setattr: always cleanup mount_kattr (bsc#1220457
  CVE-2021-46923).
- commit 89afe2f

- kABI: bpf: map_fd_put_ptr() signature kABI workaround
  (bsc#1220251 CVE-2023-52447).
- kABI: bpf: struct bpf_map kABI workaround (bsc#1220251
  CVE-2023-52447).
- kABI: bpf: map_fd_put_ptr() signature kABI workaround
  (bsc#1220251 CVE-2023-52447).
- kABI: bpf: struct bpf_map kABI workaround (bsc#1220251
  CVE-2023-52447).
- commit bec1c61

- selftests/bpf: Test outer map update operations in syscall
  program (bsc#1220251 CVE-2023-52447).
- selftests/bpf: Add test cases for inner map (bsc#1220251
  CVE-2023-52447).
- bpf: Defer the free of inner map when necessary (bsc#1220251
  CVE-2023-52447).
- Refresh patches.suse/kABI-padding-for-bpf.patch
- bpf: Set need_defer as false when clearing fd array during
  map free (bsc#1220251 CVE-2023-52447).
- bpf: Add map and need_defer parameters to .map_fd_put_ptr()
  (bsc#1220251 CVE-2023-52447).
- bpf: Check rcu_read_lock_trace_held() before calling bpf map
  helpers (bsc#1220251 CVE-2023-52447).
- rcu-tasks: Provide rcu_trace_implies_rcu_gp() (bsc#1220251
  CVE-2023-52447).
- selftests/bpf: Test outer map update operations in syscall
  program (bsc#1220251 CVE-2023-52447).
- selftests/bpf: Add test cases for inner map (bsc#1220251
  CVE-2023-52447).
- bpf: Defer the free of inner map when necessary (bsc#1220251
  CVE-2023-52447).
- Refresh patches.suse/kABI-padding-for-bpf.patch
- bpf: Set need_defer as false when clearing fd array during
  map free (bsc#1220251 CVE-2023-52447).
- bpf: Add map and need_defer parameters to .map_fd_put_ptr()
  (bsc#1220251 CVE-2023-52447).
- bpf: Check rcu_read_lock_trace_held() before calling bpf map
  helpers (bsc#1220251 CVE-2023-52447).
- rcu-tasks: Provide rcu_trace_implies_rcu_gp() (bsc#1220251
  CVE-2023-52447).
- commit aa6db76

- Update patch reference for HID fix (CVE-2023-52478 bsc#1220796)
- commit 4aec836

- Update patch reference for input fix (CVE-2023-52475 bsc#1220649)
- commit 00a87c8

- KVM: arm64: vgic-its: Avoid potential UAF in LPI translation
  cache (bsc#1220326, CVE-2024-26598).
- commit 74fd0dd

- x86/fpu: Stop relying on userspace for info to fault in xsave buffer (bsc#1220335, CVE-2024-26603).
- commit 4cbbdbf

- Update patch reference for NFC fix (CVE-2021-46924 bsc#1220459)
- commit 8ac32a8

- media: pvrusb2: fix use after free on context disconnection
  (CVE-2023-52445 bsc#1220241).
- commit e4643a5

- uio: Fix use-after-free in uio_open (bsc#1220140
  CVE-2023-52439).
- commit fbf52b1

- apparmor: avoid crash when parsed profile name is empty
  (CVE-2023-52443 bsc#1220240).
- commit 732bc93

- btrfs: do not ASSERT() if the newly created subvolume already
  got read (bsc#1219126 CVE-2024-23850).
- commit 087f1fb

- sched/membarrier: reduce the ability to hammer on sys_membarrier
  (git-fixes, bsc#1220398, CVE-2024-26602).
- commit 6f61ce3

- i2c: i801: Fix block process call transactions (bsc#1220009
  CVE-2024-26593).
- commit 1b64da9

- mlxsw: spectrum_acl_tcam: Fix stack corruption (bsc#1220243
  CVE-2024-26586).
- mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in
  error path (bsc#1220344 CVE-2024-26595).
- commit 6e8b589

- EDAC/thunderx: Fix possible out-of-bounds string access (bsc#1220330, CVE-2023-52464)
- commit 369d1fd

- Drop 2 git-fixes patches which are suspicious to introduce regression
  reported in bsc#1219073,
  - patches.suse/md-Set-MD_BROKEN-for-RAID1-and-RAID10-9631.patch.
  - patches.suse/md-raid1-free-the-r1bio-before-waiting-for-blocked-r-992d.patch.
- Refresh patches.suse/md-display-timeout-error.patch for the above
  change.
- commit 4ecd26a

- gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump
  (bsc#1220253 CVE-2023-52448).
- commit 12cdab5

- rpm templates: Always define usrmerged
  usrmerged is now defined in kernel-spec-macros and not the distribution.
  Only check if it's defined in kernel-spec-macros, not everywhere where
  it's used.
- commit a6ad8af

- nvme: remove nvme_alloc_request and nvme_alloc_request_qid
  (bsc#1214064).
  Refresh:
  - patches.suse/nvme-tcp-delay-error-recovery-until-the-next-kato.patch
- commit 6fc2117

- rpm templates: Move macro definitions below buildrequires
  Many of the rpm macros defined in the kernel packages depend directly or
  indirectly on script execution. OBS cannot execute scripts which means
  values of these macros cannot be used in tags that are required for OBS
  to see such as package name, buildrequires or buildarch.
  Accumulate macro definitions that are not directly expanded by mkspec
  below buildrequires and buildarch to make this distinction clear.
- commit 89eaf4c

- rpm/check-for-config-changes: add GCC_ASM_GOTO_OUTPUT_WORKAROUND to IGNORED_CONFIGS_RE
  Introduced by commit 68fb3ca0e408 (&amp;quot;update workarounds for gcc &amp;quot;asm
  goto&amp;quot; issue&amp;quot;).
- commit be1bdab

- net: openvswitch: limit the number of recursions from action
  sets (bsc#1219835 CVE-2024-1151).
- commit ed2fd55

- README.BRANCH: use correct mail for Roy
- commit 6f3c32f

- compute-PATCHVERSION: Do not produce output when awk fails
  compute-PATCHVERSION uses awk to produce a shell script that is
  subsequently executed to update shell variables which are then printed
  as the patchversion.
  Some versions of awk, most notably bysybox-gawk do not understand the
  awk program and fail to run. This results in no script generated as
  output, and printing the initial values of the shell variables as
  the patchversion.
  When the awk program fails to run produce 'exit 1' as the shell script
  to run instead. That prevents printing the stale values, generates no
  output, and generates invalid rpm spec file down the line. Then the
  problem is flagged early and should be easier to diagnose.
- commit 8ef8383

- nvme: move nvme_stop_keep_alive() back to original position
  (bsc#1211515).
- commit b945fa0

- x86/asm: Add _ASM_RIP() macro for x86-64 (%rip) suffix (git-fixes).
- commit 636fc4c

- KVM: VMX: Move VERW closer to VMentry for MDS mitigation (git-fixes).
- KVM: VMX: Use BT+JNC, i.e. EFLAGS.CF to select VMRESUME vs. VMLAUNCH (git-fixes).
- x86/bugs: Use ALTERNATIVE() instead of mds_user_clear static key (git-fixes).
  Also add the removed mds_user_clear symbol to kABI severities as it is
  exposed just for KVM module and is generally a core kernel component so
  removing it is low risk.
- x86/entry_32: Add VERW just before userspace transition (git-fixes).
- x86/entry_64: Add VERW just before userspace transition (git-fixes).
- x86/bugs: Add asm helpers for executing VERW (git-fixes).
- commit 5b0be3c

- netfilter: nf_tables: disallow rule removal from chain binding
  (bsc#1218216 CVE-2023-5197).
- commit d7a1a4d

- netfilter: nf_tables: skip bound chain in netns release path
  (bsc#1218216 CVE-2023-5197).
- commit af879c8

- nvme: start keep-alive after admin queue setup (bsc#1211515).
- commit 13f904b

- net/rds: Fix UBSAN: array-index-out-of-bounds in rds_cmsg_recv
  (bsc#1219127 CVE-2024-23849).
- commit 43577c1

- kernel-binary: Move build script to the end
  All other spec templates have the build script at the end, only
  kernel-binary has it in the middle. Align with the other templates.
- commit 98cbdd0

- rpm templates: Aggregate subpackage descriptions
  While in some cases the package tags, description, scriptlets and
  filelist are located together in other cases they are all across the
  spec file. Aggregate the information related to a subpackage in one
  place.
- commit 8eeb08c

- rpm templates: sort rpm tags
  The rpm tags in kernel spec files are sorted at random.
  Make the order of rpm tags somewhat more consistent across rpm spec
  templates.
- commit 8875c35

- dm: limit the number of targets and parameter size area
  (bsc#1219827, bsc#1219146, CVE-2023-52429, CVE-2024-23851).
- commit 26dc83e

- Fix unresolved hunks in README.BRANCH
- commit 99bb861

- NFS: avoid infinite loop in pnfs_update_layout (bsc#1219633).
- commit b6a1f9a

- vhost: use kzalloc() instead of kmalloc() followed by memset()
  (CVE-2024-0340, bsc#1218689).
- commit 4c5a740

- README.BRANCH: Update cve/linux-5.14 maintainers
  Add myself to match SLE15-SP5 consumer + fix typo in branch name.
- commit da26653

- Refresh patches.suse/nfsd-fix-RELEASE_LOCKOWNER.patch.
  Accidentally removed nfs4_get_stateowner
- commit d77a474

- kernel-binary: certs: Avoid trailing space
- commit bc7dc31

- Bluetooth: Fix atomicity violation in {min,max}_key_size_set
  (git-fixes bsc#1219608 CVE-2024-24860).
- commit a1186fd

- README.BRANCH: update branch name to cve/linux-5.14, update maintainers
  as requested
- commit 8e34879

- rpm/kernel-binary.spec.in: install scripts/gdb when enabled in config
  (bsc#1219653)
  They are put into -devel subpackage. And a proper link to
  /usr/share/gdb/auto-load/ is created.
- commit 1dccf2a

- netfilter: nf_tables: check if catch-all set element is active
  in next generation (CVE-2024-1085 bsc#1219429).
- commit 7b3f4c4

- netfilter: nf_tables: reject QUEUE/DROP verdict parameters
  (CVE-2024-1086 bsc#1219434).
- commit 5f917ff

- Update
  patches.suse/drm-amdgpu-Fix-potential-fence-use-after-free-v2.patch
  (bsc#1219128 CVE-2023-51042 git-fixes).
- commit 4b937fc

- rpm/mkspec: sort entries in _multibuild
  Otherwise it creates unnecessary diffs when tar-up-ing. It's of course
  due to readdir() using &amp;quot;random&amp;quot; order as served by the underlying
  filesystem.
  See for example:
  https://build.opensuse.org/request/show/1144457/changes
- commit d1155de

- Revert &amp;quot;tracing: Increase trace array ref count on enable and
  filter files&amp;quot; (bsc#1219490).
  Deleted:
  patches.suse/tracing-Increase-trace-array-ref-count-on-enable-and-filter-files.patch
  patches.suse/tracing-Have-event-inject-files-inc-the-trace-array-ref-count.patch
  Backported commit f5ca233e2e66 (&amp;quot;tracing: Increase trace array ref count
  on enable and filter files&amp;quot;) causes a kernel panic and its upstream
  fix-up bb32500fb9b7 (&amp;quot;tracing: Have trace_event_file have ref counters&amp;quot;)
  cannot be easily backported because it affects kABI. Revert the commit
  and its one related + dependent patch, at least for now.
- commit 90d885a

- README.BRANCH: SLE15-SP4 became LTSS, update maintainers
- commit 94325df

- atm: Fix Use-After-Free in do_vcc_ioctl (CVE-2023-51780
  bsc#1218730).
- commit 658d424

- xen-netback: don't produce zero-size SKB frags (CVE-2023-46838,
  XSA-448, bsc#1218836).
- commit 9a897ff

- Update
  patches.suse/ext4-fix-kernel-BUG-in-ext4_write_inline_data_end.patch
  (CVE-2021-33631 bsc#1219412 bsc#1206894).
- commit 96c942c

- kabi, vmstat: skip periodic vmstat update for isolated CPUs
  (bsc#1217895).
- commit 8cb5798

- sched/isolation: add cpu_is_isolated() API (bsc#1217895).
- trace,smp: Add tracepoints around remotelly called functions
  (bsc#1217895).
- vmstat: skip periodic vmstat update for isolated CPUs
  (bsc#1217895).
- Refresh
  patches.suse/0002-kernel-smp-make-csdlock-timeout-depend-on-boot-param.patch.
- commit 668c0e0

- kernel-source: Fix description typo
- commit 8abff35

- nvmet-tcp: Fix the H2C expected PDU len calculation
  (bsc#1217987 bsc#1217988 bsc#1217989 CVE-2023-6535 CVE-2023-6536
  CVE-2023-6356).
- nvmet-tcp: remove boilerplate code (bsc#1217987 bsc#1217988
  bsc#1217989 CVE-2023-6535 CVE-2023-6536 CVE-2023-6356).
- nvmet-tcp: fix a crash in nvmet_req_complete() (bsc#1217987
  bsc#1217988 bsc#1217989 CVE-2023-6535 CVE-2023-6536
  CVE-2023-6356).
- nvmet-tcp: Fix a kernel panic when host sends an invalid H2C
  PDU length (bsc#1217987 bsc#1217988 bsc#1217989 CVE-2023-6535
  CVE-2023-6536 CVE-2023-6356).
- commit d968940

- clocksource: Skip watchdog check for large watchdog intervals
  (bsc#1217217).
- commit 63b1d6d

- clocksource: disable watchdog checks on TSC when TSC is watchdog
  (bsc#1215885).
- commit 2f92dd8

- nfsd4: add refcount for nfsd4_blocked_lock (bsc#1218968
  bsc#1219349).
- commit d38f35d

- wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
  (CVE-2023-47233 bsc#1216702).
- commit 433859d

- rpm/constraints.in: set jobs for riscv to 8
  The same workers are used for x86 and riscv and the riscv builds take
  ages. So align the riscv jobs count to x86.
- commit b2c82b9

- net: sched: sch_qfq: Use non-work-conserving warning handler
  (CVE-2023-4921 bsc#1215275).
- commit b50ba0e

- mkspec: Use variant in constraints template
  Constraints are not applied consistently with kernel package variants.
  Add variant to the constraints template as appropriate, and expand it
  in mkspec.
- commit cc68ab9

- rpm/constraints.in: add static multibuild packages
  Commit 841012b049a5 (rpm/mkspec: use kernel-source: prefix for
  constraints on multibuild) added &amp;quot;kernel-source:&amp;quot; prefix to the
  dynamically generated kernels. But there are also static ones like
  kernel-docs. Those fail to build as the constraints are still not
  applied.
  So add the prefix also to the static ones.
  Note kernel-docs-rt is given kernel-source-rt prefix. I am not sure it
  will ever be multibuilt...
- commit c2e0681

- Update
  patches.suse/drm-atomic-Fix-potential-use-after-free-in-nonblocki.patch
  (bsc#1219120 CVE-2023-51043 git-fixes).
- commit d004027

- Revert &amp;quot;Limit kernel-source build to architectures for which the kernel binary&amp;quot;
  This reverts commit 08a9e44c00758b5f3f3b641830ab6affff041132.
  The fix for bsc#1108281 directly causes bsc#1218768, revert.
- commit 2943b8a

- mkspec: Include constraints for both multibuild and plain package always
  There is no need to check for multibuild flag, the constraints can be
  always generated for both cases.
- commit 308ea09

- rpm/mkspec: use kernel-source: prefix for constraints on multibuild
  Otherwise the constraints are not applied with multibuild enabled.
- commit 841012b

- rpm/kernel-source.rpmlintrc: add action-ebpf
  Upstream commit a79d8ba734bd (selftests: tc-testing: remove buildebpf
  plugin) added this precompiled binary blob. Adapt rpmlintrc for
  kernel-source.
- commit b5ccb33

- block: Fix kabi header include (bsc#1218929).
- commit 8f511ac

- scripts/tar-up.sh: don't add spurious entry from kernel-sources.changes.old
  The previous change added the manual entry from kernel-sources.change.old
  to old_changelog.txt unnecessarily.  Let's fix it.
- commit fb033e8

- Update
  patches.suse/ext4-improve-error-recovery-code-paths-in-__ext4_rem.patch
  (bsc#1213017 bsc#1219053 CVE-2024-0775).
- commit 97ea702

- block: free the extended dev_t minor later (bsc#1218930).
- commit 0972f94

- rpm/kernel-docs.spec.in: fix build with 6.8
  Since upstream commit f061c9f7d058 (Documentation: Document each netlink
  family), the build needs python yaml.
- commit 6a7ece3

- hv_netvsc: rndis_filter needs to select NLS (git-fixes).
- commit 6f3116b

- nfsd: fix RELEASE_LOCKOWNER (bsc#1218968).
- commit 605df5b

- netfilter: nf_tables: Reject tables of unsupported family
  (bsc#1218752 CVE-2023-6040).
- commit e03f1d3

- bcache: revert replacing IS_ERR_OR_NULL with IS_ERR (git-fixes).
- bcache: replace a mistaken IS_ERR() by IS_ERR_OR_NULL() in
  btree_gc_coalesce() (git-fixes).
- rbd: take header_rwsem in rbd_dev_refresh() only when updating
  (git-fixes).
- dm: don't lock fs when the map is NULL during suspend or resume
  (git-fixes).
- commit fe9ee72

- tipc: fix a potential deadlock on &amp;amp;tx-&amp;gt;lock (bsc#1218916
  CVE-2024-0641).
- commit c872674

- Update metadata
- commit d121b79

- tipc: fix a potential deadlock on &amp;amp;tx-&amp;gt;lock (bsc#1218916
  CVE-2024-0641).
- commit 7953be2

- Update metadata
- commit c015ae2

- smb: client: fix OOB in receive_encrypted_standard()
  (bsc#1218832 CVE-2024-0565).
- commit 3cac9c2

- ida: Fix crash in ida_free when the bitmap is empty (bsc#1218804
  CVE-2023-6915).
- commit 7caa324

- dm-integrity: don't modify bio's immutable bio_vec in
  integrity_metadata() (git-fixes).
- dm-verity: align struct dm_verity_fec_io properly (git-fixes).
- dm verity: don't perform FEC for failed readahead IO
  (git-fixes).
- bcache: avoid NULL checking to c-&amp;gt;root in run_cache_set()
  (git-fixes).
- bcache: add code comments for bch_btree_node_get() and
  __bch_btree_node_alloc() (git-fixes).
- bcache: fixup multi-threaded bch_sectors_dirty_init() wake-up
  race (git-fixes).
- bcache: fixup lock c-&amp;gt;root error (git-fixes).
- bcache: fixup init dirty data errors (git-fixes).
- bcache: prevent potential division by zero error (git-fixes).
- bcache: remove redundant assignment to variable cur_idx
  (git-fixes).
- bcache: check return value from btree_node_alloc_replacement()
  (git-fixes).
- bcache: avoid oversize memory allocation by small stripe_size
  (git-fixes).
- dm-delay: fix a race between delay_presuspend and delay_bio
  (git-fixes).
- dm zoned: free dmz-&amp;gt;ddev array in dmz_put_zoned_devices
  (git-fixes).
- rbd: decouple parent info read-in from updating rbd_dev
  (git-fixes).
- rbd: decouple header read-in from updating rbd_dev-&amp;gt;header
  (git-fixes).
- rbd: move rbd_dev_refresh() definition (git-fixes).
- rbd: prevent busy loop when requesting exclusive lock
  (git-fixes).
- rbd: retrieve and check lock owner twice before blocklisting
  (git-fixes).
- rbd: harden get_lock_owner_info() a bit (git-fixes).
- rbd: make get_lock_owner_info() return a single locker or NULL
  (git-fixes).
- dm cache policy smq: ensure IO doesn't prevent cleaner policy
  progress (git-fixes).
- dm raid: clean up four equivalent goto tags in raid_ctr()
  (git-fixes).
- dm raid: fix missing reconfig_mutex unlock in raid_ctr()
  error paths (git-fixes).
- dm integrity: reduce vmalloc space footprint on 32-bit
  architectures (git-fixes).
- dm thin metadata: Fix ABBA deadlock by resetting dm_bufio_client
  (git-fixes).
- bcache: fixup btree_cache_wait list damage (git-fixes).
- bcache: Fix __bch_btree_node_alloc to make the failure behavior
  consistent (git-fixes).
- bcache: Remove unnecessary NULL point check in node allocations
  (git-fixes).
- dm thin metadata: check fail_io before using data_sm
  (git-fixes).
- commit 7e800d7

- rbd: get snapshot context after exclusive lock is ensured to
  be held (git-fixes).
- Refresh for the above change,
  patches.suse/rbd-export-some-functions-used-by-lio-rbd-backend.patch.
  patches.suse/target_core_rbd-fix-rbd_img_request.snap_id-assignme.patch.
- commit dcd100d

- rbd: move RBD_OBJ_FLAG_COPYUP_ENABLED flag setting (git-fixes).
- Rebased for the above change,
  patches.suse/rbd-add-support-for-COMPARE_AND_WRITE-CMPEXT.patch.
- commit b5f85f8

- nbd: Fix debugfs_create_dir error checking (git-fixes).
- dm: don't lock fs when the map is NULL in process of resume
  (git-fixes).
- dm flakey: fix a crash with invalid table line (git-fixes).
- dm integrity: call kmem_cache_destroy() in dm_integrity_init()
  error path (git-fixes).
- dm clone: call kmem_cache_destroy() in dm_clone_init() error
  path (git-fixes).
- dm verity: fix error handling for check_at_most_once on FEC
  (git-fixes).
- nbd: fix incomplete validation of ioctl arg (git-fixes).
- null_blk: Always check queue mode setting from configfs
  (git-fixes).
- dm stats: check for and propagate alloc_percpu failure
  (git-fixes).
- dm crypt: avoid accessing uninitialized tasklet (git-fixes).
- dm crypt: add cond_resched() to dmcrypt_write() (git-fixes).
- commit ad93a37

- dm thin: fix deadlock when swapping to thin device
  (bsc#1177529).
- Delete the in-house patch by the above upstream patch,
  patches.suse/Avoid-deadlock-for-recursive-I-O-on-dm-thin-when-used-as-swap-4905.patch.
- commit 13bcec1

- rbd: avoid use-after-free in do_rbd_add() when rbd_dev_create()
  fails (git-fixes).
- dm cache: add cond_resched() to various workqueue loops
  (git-fixes).
- dm thin: add cond_resched() to various workqueue loops
  (git-fixes).
- dm: add cond_resched() to dm_wq_work() (git-fixes).
- dm: remove flush_scheduled_work() during local_exit()
  (git-fixes).
- dm: send just one event on resize, not two (git-fixes).
- dm flakey: fix logic when corrupting a bio (git-fixes).
- dm flakey: don't corrupt the zero page (git-fixes).
- dm init: add dm-mod.waitfor to wait for asynchronously probed
  block devices (git-fixes).
- loop: suppress uevents while reconfiguring the device
  (git-fixes).
- commit 2a9583d

- nbd: use the correct block_device in nbd_bdev_reset (git-fixes).
- Refresh for the above change,
  patches.suse/0019-nbd-fix-io-hung-while-disconnecting-device.patch.
  patches.suse/0031-nbd-Fix-hung-when-signal-interrupts-nbd_start_device_ioctl.patch.
- commit 2cb1a83

- blacklist.conf: add non-backport git-fixes commit
- commit ab480ce

- dm verity: skip redundant verity_handle_err() on I/O errors
  (git-fixes).
- commit 7d823a7

- Update
  patches.kabi/NFS-Fix-another-fsync-issue-after-a-server-reboot.patch
  (git-fixes, bsc#1217670).
- commit 69dfe32

- blacklist.conf: df1c357f25d8 netfs: Only call folio_start_fscache() one time for each folio
- commit 049ab09

- intel_idle: add Emerald Rapids Xeon support (bsc#1216016).
- commit 30bac4b

- Update patch reference for rose fix (CVE-2023-51782 bsc#1218757)
- commit da9f8e9

- blacklist.conf: c4d361f66ac9 fuse: share lookup state between submount and its parent
- commit 3180cfa

- powerpc/powernv: Add a null pointer check to
  scom_debug_init_one() (bsc#1194869).
- commit 5dce54b

- powerpc/pseries/iommu: enable_ddw incorrectly returns direct
  mapping for SR-IOV device (bsc#1212091 ltc#199106 git-fixes).
- commit f20e9a0

- powerpc/powernv: Add a null pointer check in opal_event_init()
  (bsc#1065729).
- commit 9ecfceb

- Store the old kernel changelog entries in kernel-docs package (bsc#1218713)
  The old entries are found in kernel-docs/old_changelog.txt in docdir.
  rpm/old_changelog.txt can be an optional file that stores the similar
  info like rpm/kernel-sources.changes.old.  It can specify the commit
  range that have been truncated.  scripts/tar-up.sh expands from the
  git log accordingly.
- commit c9a2566

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

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

- tail: fix tailing sysfs files where PAGE_SIZE &amp;gt; BUFSIZ (bsc#1219321)
  - add coreutils-tail-fix-tailing-sysfs-files-where-PAGE_SIZE-BUFSIZ.patch

Package crmsh was updated:

- Update to version 4.4.2+20240424.6adcc38:  * Fix: bootstrap: Remove unused -i option when calling csync2_remote and ssh_remote stage (bsc#1212080)
  * Fix: utils: pass env to child process explicitly (bsc#1205925)
  * Fix: utils: set env `CIB_shadow` using `os.environ` (bsc#1205925)
  * Fix: pass env to child process explicitly (bsc#1205925)
  * Fix: term: unset env `COLUMNS` and `ROWS` (bsc#1205925)

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

- Remove '--enable-debug-printfs' from configure options, see
  https://github.com/OpenPrinting/cups/issues/875
  (bsc#1217119).

Package curl was updated:

- Security fix: [bsc#1221665, CVE-2024-2004]  * Usage of disabled protocol
  * Add curl-CVE-2024-2004.patch

- Security fix: [bsc#1221667, CVE-2024-2398]
  * curl: HTTP/2 push headers memory-leak
  * Add curl-CVE-2024-2398.patch

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.

[NOTE: This update was only ever released in SLES and Leap.]
- Add patch to fix bsc#1220339
  * 0007-daemon-overlay2-remove-world-writable-permission-fro.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
  * 0006-Vendor-in-latest-buildkit-v0.11-branch-including-CVE.patch

- Allow to disable apparmor support (ALP supports only SELinux)

- Update to Docker 25.0.3-ce. See upstream changelog online at
  &amp;lt;https://docs.docker.com/engine/release-notes/25.0/#2503&amp;gt;
- Fixes:
  * bsc#1219267 - CVE-2024-23651
  * bsc#1219268 - CVE-2024-23652
  * bsc#1219438 - CVE-2024-23653
- 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:
  - 0006-Vendor-in-latest-buildkit-v0.11-branch-including-CVE.patch

- Vendor latest buildkit v0.11:
  Add patch 0006-Vendor-in-latest-buildkit-v0.11-branch-including-CVE.patch that
  vendors in the latest v0.11 buildkit branch including bugfixes for the following:
  * bsc#1219438: CVE-2024-23653
  * bsc#1219268: CVE-2024-23652
  * bsc#1219267: CVE-2024-23651
- 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
- switch from %patchN to %patch -PN syntax
- remove unused rpmlint filters and add filters to silence pointless bash &amp;amp; zsh
  completion warnings

Package dracut was updated:

- Update to version 055+suse.357.g905645c2:  * fix(dracut-install): continue parsing if ldd prints &amp;quot;cannot be preloaded&amp;quot; (bsc#1208690)
  * fix(zfcp_rules): correct shellcheck regression when parsing ccw args (bsc#1220485)
  * fix(dracut.sh): skip README for AMD microcode generation (bsc#1217083)

Package e2fsprogs was updated:

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

Package expat was updated:

- Security fix (boo#1221289, CVE-2024-28757): XML Entity Expansion  attack when there is isolated use of external parsers.
  * Added expat-CVE-2024-28757.patch

- Security fix:
  * (CVE-2023-52425, bsc#1219559) denial of service (resource
    consumption) caused by processing large tokens.
  - Added patch expat-CVE-2023-52425-1.patch
  - Added patch expat-CVE-2023-52425-2.patch
  - Added patch expat-CVE-2023-52425-backport-parser-changes.patch
  - Added patch expat-CVE-2023-52425-fix-tests.patch

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)

- iconv-iso-2022-cn-ext.patch: iconv: ISO-2022-CN-EXT: fix out-of-bound
  writes when writing escape sequence (CVE-2024-2961, bsc#1222992)

- duplocale-global-locale.patch: duplocale: protect use of global locale
  (bsc#1220441, BZ #23970)

- qsort-invalid-cmp.patch: qsort: handle degenerated compare function
  (bsc#1218866)

- getaddrinfo-eai-memory.patch: getaddrinfo: translate ENOMEM to
  EAI_MEMORY (bsc#1217589, BZ #31163)

- aarch64-rawmemchr-unwind.patch: aarch64: correct CFI in rawmemchr
  (bsc#1217445, BZ #31113)

Package gnutls was updated:

- Security fix: [bsc#1221747, CVE-2024-28835]  * gnutls: certtool crash when verifying a certificate chain
  * Add gnutls-CVE-2024-28835.patch

- Security fix: [bsc#1221746, CVE-2024-28834]
  * gnutls: side-channel in the deterministic ECDSA
  * Add gnutls-CVE-2024-28834.patch

- jitterentropy: Release the memory of the entropy collector when
  using jitterentropy with phtreads as there is also a
  pre-intitization done in the main thread. [bsc#1221242]
  * Add gnutls-FIPS-jitterentropy-deinit-threads.patch

- Security fix: [bsc#1218862, CVE-2024-0567]
  * gnutls: rejects certificate chain with distributed trust
  * Cockpit (which uses gnuTLS) rejects certificate chain with
    distributed trust.
  * Add gnutls-CVE-2024-0567.patch

- Security fix: [bsc#1218865, CVE-2024-0553]
  * Incomplete fix for CVE-2023-5981.
  * The response times to malformed ciphertexts in RSA-PSK
    ClientKeyExchange differ from response times of ciphertexts
    with correct PKCS#1 v1.5 padding.
  * Add gnutls-CVE-2024-0553.patch

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.

- Update to version 3.2 (bsc#1222215, bsc#1222216)
  * Remove internal gensupport package.
  * Restore additional error handling and response checking to internal data warehouse client.
  * Updating the aggregate function in HANA insight rules
  * Remove a leftover debug log
  * Allow multipart uploads for PIPE file types.
  * Update go-hdb version to v1.8.0
  * Perform log restores in serial rather than parallel.
  * Add sample usage examples to commandlineexecutor
  * Small update to configureinstance OTE
  * Add nil check in backup and restore flows to protect against panics.
  * Close http response body in WriteInsight() and soap.go
  * Record topology type.
  * Initialize usagemetrics for OTEs
  * Add Instance Number to SAP System instance properties
  * Set `min_version` for WLM `os_settings` system metric.
  * Increase timeout for saptune re-apply commands.
  * Adding handling for encrypted snapshots in backup and restore
  * Change the version check comparisons to account for versions
    older than those listed in SAP Note.
  * Skip the Netweaver metrics that need dpmon on NW kernels
    affected by SAP Note: 3366597
  * Fix imports
  * No public description
  * Use internal data warehouse client.
  * Fix disp+work command invocation for Netweaver Kernel version discovery.
  * Add note about default parameter values to installbackint.
  * Add mutex in multipart writer for potential data races.
  * Update go.mod and go.sum
  * Skip XFS freeze by default unless user passes a parameter to do it explicitly
  * configureinstance minor updates.
  * Add safety check for usage metrics on BMS
  * Storage Class parameter added to Backint.
  * Update configureinstance's X4 saptune conf.
  * XML Multipart Write() and Close() methods completed.
  * Fixes the vmmanager policies for sles12 and sles15 used in the cloud console removes
    the individual cloud console policies and consolidates them into one Adds a general
    gcloud command line policy
  * Standardize logging for workloadmanager package.
  * Multipart XML API Uploads for Backint.
  * Add database system SID to database properties.
  * Fix NW HA node identification for RedHat deployments.
  * Add workload properties to discovery object returned by discoverSAPSystems
  * Add ASCS instance number to application data
  * Add Workload Manager validation rule for checking OS settings.
  * Enable WLM metric collection by default, disable submission of data to Cloud Monitoring.
  * Decoupling primary executable command and providing an alternative to lsof
  * Added HANA version in support bundle collection
  * Add WorkloadProperties to merged system details and to WLM Insights
  * Replace the link placeholder with the actual link
  * Add instance number to SAP discovery data
  * Tranche 12: HRE Rules
  * Minor typo fix in workloadmanager's hana metrics module
  * Add pacemaker metrics with SID labels to process metrics
  * updating the regex for backup and backint files to take care of log rotation in support bundle
  * Add support for disk snapshot labels for easy lifecycle management of snapshots
  * Added new OTE for changedisktype workflow
  * Add WorkloadProperties to SapSystemDetails for apps_discovery
  * Testing the timeseries in unit tests instead of just checking the count
  * Record Netweaver kernel version.
  * Tranche 12: HRE Rules
  * Testing the timeseries in unit tests instead of just checking the count
  * Testing the timeseries in unit tests instead of just checking the count
  * Relocating pacemaker collection related packages to internal/pacemaker
    for common use between process metrics and WLM
  * Use results from latest round of discovery for the collection of process metrics.
  * Handling zero rows returned case better in HANA insights
  * Adding docstrings to workloadmanager package
  * Adding docstring to configure OTE
  * adding docstrings to methods in support bundle
  * Add X4 specific configurations to configureinstance OTE.
  * Add helper functions to configureinstance OTE.
  * Display updates for HANA Insights WLM rules rollout.
  * configureinstance OTE
  * We expect the command to return a non-zero exit code and we should not be
    returning an error. Execute treats non-zero exit code as error.
  * Removing the sap control process command line params
  * Revert &amp;quot;Fixing system replication status code being returned&amp;quot;
  * configureinstance OTE
  * We expect the command to return a non-zero exit code and we should not be
    returning an error. Execute treats non-zero exit code as error.
  * Removing the sap control process command line params
  * Fixing system replication status code being returned
  * Wait for hdbindex server to stop after HANA is stopped
  * Log error to console in cases where LVM is not being used
  * Adding JournalCTL logs to support bunddle
  * hanadiskbckup - Add missing params to the Usage string
  * Move usagemetrics package into shared folder
  * Fixed data race error in TestCollectAndSendSlowMovingMetrics()
  * Disk backup/restore - Enable send-metrics-to-monitoring by default

- Update to version 3.1 (bsc#1220010, bsc#1220111)
  * Fixing system replication status code being returned
  * Reduce disk snapshot wait durations
  * Fix test flakes in workloadcollector test.
  * adding metrics for db freeze time and total workflow time
  * Fix for SAP System discovery adding the current host to all components.
  * Restore default WLM metric collection settings.
  * change description of validate OTE
  * fix a typo in the command name and add a delay before we try the unmount
  * Use underscore as separator for flags in place of hyphens
  * Enable host_metrics and disable reliability_metrics by default in configure OTE
  * Collect reliability metrics in the free namespace
  * Remove user from cmd params for HANA Replication
  * Enable workload manager metric collection by default.
  * Add support configuration flag to enable legacy WLM metric data submission workflow.
  * Lowers the log level of discovery to info
  * Fix for HANA Replication Config
  * Add additional instance-id parameter for users who do not want to provide port number
  * Use _ instead of - for parameters in configurebackint
  * Implementing panic recovery to HANA Monitoring: CreateWorkerPool
  * Fix issue with process metrics subroutine starting.
  * Add a flag to enable or disable workload discovery.
  * Reduce logs in sapdiscovery to debug, these are now run a
    lot more frequently and are flooding the logs
  * Use bucket `cloudsapdeploystaging` for staging environment.
  * Updates default value handling for system discovery flag.
  * Added default values to some frequency flags in configure OTE
  * force a sync before unmounting to clear out stale file handles
  * Retain recoverable routine in process metrics.
  * Ensures slow metrics workers stop on context cancellation.
  * Log lsof output if unmount fails during restore
  * SAP Discovery - Discover R3trans data
  * Add panic recovery to collectiondefinition update routine
  * configurebackint OTE.
  * Adding panic recovery to remote.go
  * Prevent host metrics from restarting the daily metrics report if it has already been started.
  * Add panic recovery to agent metrics
  * Implementing panic recovery for hana monitoring: logging action daily
  * Routines now use their own context and cancel in the event of a panic recovery.
  * Add panic recovery to host metrics routines
  * Removed -path flag and fixed usage string
  * Add workload properties to the SAP System definition.
  * Add panic recovery to collectMetricsFromConfig routines.
  * Add panic recovery to fast metric collection routine.
  * Reduces the log severity to debug for the exponential backoff policy
  * Add panic recovery to heartbeat routine.
  * Updating configuration.json file to remove deprecated sap_discovery field
  * Use protojson instead of custom function for snake_case marshaling
  * Add panic recovery to WLM metrics collection
  * HANA Insights rules tranche 11: Create unit tests and add to auto push
  * Add panic recovery to workload collector daily usage metrics.
  * Processmetrics - suppress Error and Warn logs that really need to be debug
  * Formatting the output of messages printed by configure OTE
  * Changing flag names of configure OTE to align better with configuration.json fields
  * Add automatic panic recovery to slow metrics collection
  * Add panic recovery to goroutine collectAndSend
  * Add panic recovery to goroutine
  * Retain recoverable routines beyond function scope.
  * Implement recovery handler for SAP System discovery package
  * Tranche 11: HRE Rules
  * Update github build
  * Adds generic panic recovery to SAP System discovery package
  * Initialize the sidadm env to ensure restore can be run as root user
  * not pacaking gcbdr scripts till launch of the feature
  * Change datatype of frequency flags from string to int
  * Breaking down --frequency flag into separate flags for different features for better isolation
  * Fix configuration.json file from being written in camelCase to snake_case
  * Tranche 6,7,8,9,10: HRE Rules
  * Suppress pacemaker related log from Error to Debug
  * creating the OTE for GCBDR discovery
  * Update HA node identification
  * Tranche 10: HRE Rules
  * Update file permissions and ownership for installbackint when running as root.
  * Adding newline after version print.
  * Exposing HANA Logical volumes availability metrics
  * Make workloadmanager parameters test more robust.
  * Fix panic in cloud discovery
  * Tranche 10: HRE Rules
  * Add recovery_folder_prefix parameter to Backint.
  * Mark process_metrics_send_frequency as deprecated
  * Add snapshot-type param to hanadiskbackup with default as STANDARD
    type. Users can override to ARCHIVE type if needed.
  * Add new folder_prefix parameter to Backint.
  * Add HANA new HANA insight rules to BUILD file and embed sources
  * Tranche 10a: HRE Rules
  * Tranche 6b: HRE Rules
  * Tranche 8b: HRE Rules
  * Fix for sending isABAP value
  * Updating logusage command line flags

- Update to version 3.0 (bsc#1218736, bsc#1218737)
  * Suppress packemaker command error to debug to avoid log flooding
  * Expand load balancing cluster discovery.
  * Log success messages in OTEs to STDOUT instead of STDERR used by log.Print
  * Use bash always to avoid variation of behavior across OS/Shell types
  * Minor updates to installbackint.
  * Backint compose step properly saves metadata.
  * Fix issue with discovery on ASCS instances.
  * hanadiskrestore - fix the format of disktype string for disk create API
  * Fix issue with PCS cluster address discovery.
  * Update transform to insight
  * Rename HANA backup/restore OTEs to reflect they are supported
    for all disks and not just persistent disk
  * Increase the timeout for HDB stop to account for busy DBs
  * Adding project sap-ecs-testing to the list.
  * PD Restore - Support provisioned-iops and provisioned-throughput
  * Integration test for configure OTE
  * Added precondition in hana pd backup for stripped LVM
  * Add a precondition check to verify user has passed a valid
    snapshot name that is present in the current project
  * Update the usage to reflect additional required param
  * Minor path update for supportbundle OTE.
  * Fixing bug in slow moving metrics partial collection scenarios
  * Adding check for agent status after restart.
  * Ensure Backint ComposeChunks has a valid bucket handle
  * Discover whether a Netweaver instance is ABAP or Java
  * Replace standard slices package with third party version
  * WLM HANA metric `ha_in_same_zone` now reports instance
    names for HA nodes in the same zone
  * Fix data race condition for Backint Backup with new client connections
  * Make -new-disk-name a required parameter to avoid the 63 char
    limit in the name length due to auto-generated names
  * Fix command for collecting Corosync metric `two_node_runtime`
  * Make snapshot name similar to disk name
  * Bump golang.org/x/crypto from 0.15.0 to 0.17.0
  * Enable Discovery config flag controls submission
    to Data Warehouse and Cloud Logging
  * Create new clients for each operation in Backint
  * Add `client_endpoint` to Backint proto.
  * Getting the build number into the version for display
  * Backint config name change: service_account to service_account_key
  * Add HANA HA metrics to collection definition.
  * Fix sorting bug in a diff in apps_discovery_test.go
  * Add discoverHANATenantDBs to main code path
  * Change PIPE filemode to WRONLY to allow us to detect broken pipes
  * Deprecate `sap_system_discovery` config field in favor of `enable_discovery`
  * Move the validation of whether user passed correct PD, before stopping HANA
  * Add a placeholder for public doc link with next steps
    after hanapdrestore workflow has completed
  * Fix executable path for HDB version command
  * Add optional param `new-disk-name` to hanapdrestore
    for users that wish to override the default
  * Sort the skipmetrics in unit test to avoid order related flakes
  * Generalizing configure OTE
  * Discover Netweaver kernel version
  * Fix Sprintf call
  * Use SAP System data to determine if HANA HA nodes share the same zone.
  * hanapdrestore - do not delete PDs in case of failures
  * Create discoverHANATenantDBs method to support multiple SIDs for HANA tenant DBs
  * Send additional fields in Data Warehouse WriteInsightRequest
  * Updating the username parameters for hana pd backup and restore
  * Retrieve Reliability data every 2 hours instead of 24
  * Discover HANA version
  * Fix import for GitHub build
  * Add instance properties, and topology information to system data
  * Keep the device nam and disk name same after restore
  * Move sapdiscovery package into system package
  * Changer the default name of the disk created by restore workflow
  * Updates the generated protobuf go for system.proto
  * Update generated system proto
  * Update go.yml
  * Add topology and instance properties info to SAP System data
  * Add a check to verify the disk is attached to instance, fail if disk is not attached
  * Add application and database software properties to system representation
  * Fix race condition in heartbeat test case
  * Add error handling to restore workflow to try and keep
    the HANA system in a clean state on failures
  * Enable LogToCloud by default for both OTE and Daemon modes
  * Bump Agent version to 3.0
  * Reliability OTE added to SAP Agent
  * Declare public Get interface for SAP System discovery data
  * Integration testing for Networkstats Package
  * Adding project sap-ecs-testing to the list
  * Adding one time execution for enabling/disabling of features
  * Change to using custom retries for initial bucket connection
  * Default collection definition to be fetched from GCS
  * Add a 2 minute context timeout for initial bucket connection
  * Add `collection_config_version` as a WLM system metric
  * Make project, host param optional for hanapdbackup,
    in addition make user param optional for hanapdrestore
  * Fix potential nil dereference WLM metrics collection
  * Add force-stop-hana to restore workflow to forcefully stop
    HANA when the param is passed
  * Rename the HANA PD snapshot and restore workflows
  * Add unit tests for GetProvisionIOps and GetProvisionedThoughput
  * Remove the TestCollect unit test which relies on nc
    command which can be flaky in unit tests
  * Increase Backint timeout for PIPE files to 3 minutes
  * Add XFS freeze and unfreeze to PD based snapshot

Package google-guest-agent was updated:

- Update to version 20240314.00 (bsc#1221900, bsc#1221901)  * NetworkManager: only set secondary interfaces as up (#378)
  * address manager: make sure we check for oldMetadata (#375)
  * network: early setup network (#374)
  * NetworkManager: fix ipv6 and ipv4 mode attribute (#373)
  * Network Manager: make sure we clean up ifcfg files (#371)
  * metadata script runner: fix script download (#370)
  * oslogin: avoid adding extra empty line at the end of /etc/security/group.conf (#369)
  * Dynamic vlan (#361)
  * Check for nil response (#366)
  * Create NetworkManager implementation (#362)
  * Skip interface manager on Windows (#363)
  * network: remove ignore setup (#360)
  * Create wicked network service implementation and its respective unit (#356)
  * Update metadata script runner, add tests (#357)
  * Refactor guest-agent to use common retry util (#355)
  * Flush logs before exiting #358 (#359)
- Refresh patches for new version
  * dont_overwrite_ifcfg.patch

- No need for double %setup.

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

- Update to version 20240213.00
  * Create systemd-networkd unit tests (#354)
- from version 20240209.00
  * Update network manager unit tests (#351)
- from version 20240207.02
  * Implement retry util (#350)
- from version 20240207.01
  * Refactor utils package to not dump everything unrelated into one file (#352)
- from version 20240207.00
  * Set version on metadata script runner (#353)
  * Implement cleanup of deprecated configuration directives (#348)
  * Ignore DHCP offered routes only for secondary nics (#347)
  * Deprecate DHClient in favor of systemd-networkd (#342)
  * Generate windows and linux licenses (#346)
- from version 20240122.00
  * Remove quintonamore from OWNERS (#345)
- from version 20240111.00
  * Delete integration tests (#343)
- from version 20240109.00
  * Update licenses with dependencies of go-winio (#339)
  * Add github.com/Microsoft/go-winio to third party licensing (#337)
- Add explicit versioned dependency on google-guest-oslogin (bsc#1219642)
- Refresh patches for new version
  * dont_overwrite_ifcfg.patch

- Update to version 20231214.00
  * Fix snapshot test failure (#336)
- from version 20231212.00
  * Implement json-based command messaging system for guest-agent (#326)
- from version 20231118.00
  * sshca: Remove certificate caching (#334)
- from version 20231115.00
  * revert: 3ddd9d4a496f7a9c591ded58c3f541fd9cc7e317 (#333)
  * Update script runner to use common cfg package (#331)

- Update to version 20231110.00
  * Update Google UEFI variable (#329)
  * Update owners (#328)
- from version 20231103.00
  * Make config parsing order consistent (#327)

Package google-guest-configs was updated:

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

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

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

Package google-guest-oslogin was updated:

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

- Add explicit versioned dependency on google-guest-agent (bsc#1219642)

- Update to version 20231116.00
  * build: Fix DESTDIR concatenation (#124)
- from version 20231113.00
  * build: Fix clang build (#122)
- from version 20231103.00
  * Update owners (#121)

Package google-osconfig-agent was updated:

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

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

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

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

Package graphviz was updated:

- VUL-0: CVE-2023-46045: graphviz: out-of-bounds read via a crafted config6a file  bsc#1219491
  A gvc-detect-plugin-installation-failure-and-display-an-error.patch

Package growpart-rootgrow was updated:

- Update to version 1.0.7 (bsc#1219941)  + Support root to be in a btrfs snapshot
  + 1.0.6 had different implementation for btrfs in snapshot support

Package gtk2 was updated:

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

Package hawk2 was updated:

- Update to version 2.6.4+git.1708604510.dc8c081f:  * Enable ACL (bsc#1214396,bsc#1219548)

Package ipset was updated:

- Fix build with latest kernel, bsc#1223370  * bsc1223370.patch

Package iputils was updated:

- Backport upstream fix for bsc#1225963  b589819 (&amp;quot;arping: Fix exit code if receive more replies than sent&amp;quot;)
  0001-arping-Fix-exit-code-if-receive-more-replies-than-se.patch

- 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  0013-Fix-vulnerabilities-in-GSS-message-token-handling.patch
  * CVE-2024-37370, bsc#1227186
  * CVE-2024-37371, bsc#1227187

- Fix memory leaks, add patch 0012-Fix-two-unlikely-memory-leaks.patch
  * CVE-2024-26458, bsc#1220770
  * CVE-2024-26461, bsc#1220771

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

- resource-agents:azure-lb IPv6 support (bsc#1220997)
  Add patch:
    0001-Support-IPv6-with-Azure-load-balncer.patch

Package less was updated:

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

- Fix CVE-2022-48624, LESSCLOSE handling in less does not quote shell
  metacharacters, bsc#1219901
  * CVE-2022-48624.patch

Package gcc13 was updated:

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

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

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

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

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

- Revert libgccjit dependency change.  [boo#1220724]

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

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

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

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

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

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

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

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

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

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

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

Package avahi was updated:

- Add avahi-CVE-2023-38471.patch: Extract host name using  avahi_unescape_label (bsc#1216594, CVE-2023-38471).
- Add avahi-CVE-2023-38469.patch: Reject overly long TXT resource
  records (bsc#1216598, CVE-2023-38469).

Package util-linux was updated:

- Properly neutralize escape sequences in wall  (util-linux-CVE-2024-28085.patch, bsc#1221831, CVE-2024-28085,
  and its prerequisites: util-linux-fputs_careful1.patch,
  util-linux-wall-migrate-to-memstream.patch
  util-linux-fputs_careful2.patch).

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

Package cairo was updated:

- Add cairo-fix-infinite-loop-bsc1122321-CVE-2019-6462.patch: This  fixes a potentially infinite loop (bsc#1122321, CVE-2019-6462,
  glfo#cairo/cairo#155).

Package c-ares was updated:

- CVE-2024-25629.patch: fix out of bounds read in ares__read_line()  (bsc#1220279, CVE-2024-25629)

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

- update to NSS 3.90.2
  * bmo#1780432 - (CVE-2023-5388) Timing attack against RSA
    decryption in TLS. (bsc#1216198)
  * bmo#1867408 - add a defensive check for large ssl_DefSend
    return values.

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

- Add patch ncurses-6.1-bsc1220061.patch (bsc#1220061, CVE-2023-45918)  * Backport from ncurses-6.4-20230615.patch
    improve checks in convert_string() for corrupt terminfo entry

Package nftables was updated:

- port python-single-spec logic from Factory package to allow shipment of  python311 modules as well (bsc#1219253).

Package nghttp2 was updated:

- security update- added patches
  fix CVE-2024-28182 [bsc#1221399], HTTP/2 CONTINUATION frames can be utilized for DoS attacks
  + nghttp2-CVE-2024-28182-1.patch
  fix CVE-2024-28182-2 [bsc#1221399], HTTP/2 CONTINUATION frames can be utilized for DoS attacks
  + nghttp2-CVE-2024-28182-2.patch

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

- Security fix: [bsc#1219243, CVE-2024-0727]
  * Add NULL checks where ContentInfo data can be NULL
  * Add openssl-CVE-2024-0727.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

- tools: Hook up the verbosity flag in crm_attribute. (gh#ClusterLabs/pacemaker#2696, bsc#1224183)
  * pacemaker#2696-0001-Low-tools-Hook-up-the-verbosity-flag-in-crm_attribut.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

- 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

- libcrmcommon: Always output request= in XML output. (gh#ClusterLabs/pacemaker#3362)
  * pacemaker#3362-0001-Low-libcrmcommon-Always-output-request-in-XML-output.patch

- tools: crm_attribute emits garbage for --node localhost or auto (gh#ClusterLabs/pacemaker#3339)
  * pacemaker#3339-0001-Fix-tools-crm_attribute-emits-garbage-for-node-local.patch
- tools: Fix memory leak in crm_mon with HTML output (gh#ClusterLabs/pacemaker#3332)
  * pacemaker#3332-0001-Low-tools-Fix-memory-leak-in-crm_mon-with-HTML-outpu.patch

- tools: crm_mon segfaults when fencer connection is lost (bsc#1219220, gh#ClusterLabs/pacemaker#3331)
  * bsc#1219220-0001-Fix-tools-crm_mon-segfaults-when-fencer-connection-i.patch

- attrd: write Pacemaker Remote node attributes even if not in cache (gh#ClusterLabs/pacemaker#3304)
  * pacemaker#3304-0001-Fix-attrd-write-Pacemaker-Remote-node-attributes-eve.patch
- agents: Use attrd_updater dampen delay in SysInfo (gh#ClusterLabs/pacemaker#3286)
  * pacemaker#3286-0002-Fix-agents-Use-attrd_updater-dampen-delay-in-SysInfo.patch
- libcrmcommon: Check correct env vars in pcmk__node_attr_target() (gh#ClusterLabs/pacemaker#3286)
  * pacemaker#3286-0001-Low-libcrmcommon-Check-correct-env-vars-in-pcmk__nod.patch

- scheduler: restore nvpair behavior without id-ref (gh#ClusterLabs/pacemaker#3292)
  * pacemaker#3292-0004-Low-scheduler-restore-nvpair-behavior-without-id-ref.patch
- libcrmcommon: fix NULL dereference in expand_idref() (gh#ClusterLabs/pacemaker#3292)
  * pacemaker#3292-0002-Low-libcrmcommon-fix-NULL-dereference-in-expand_idre.patch
- scheduler: improve logs for invalid id-ref's (gh#ClusterLabs/pacemaker#3292)
  * pacemaker#3292-0001-Log-scheduler-improve-logs-for-invalid-id-ref-s.patch
- pacemaker-attrd,libcrmcluster: avoid use-after-free when remote node in cluster node cache (gh#ClusterLabs/pacemaker#3293)
  * pacemaker#3293-0002-Fix-pacemaker-attrd-libcrmcluster-avoid-use-after-fr.patch
- libcrmcluster: avoid use-after-free in trace log (gh#ClusterLabs/pacemaker#3293)
  * pacemaker#3293-0001-Low-libcrmcluster-avoid-use-after-free-in-trace-log.patch
- HealthSmart: Check the parameter values of check_temperature to avoid error output (gh#ClusterLabs/pacemaker#3289)
  * pacemaker#3289-0001-Fix-HealthSmart-Check-the-parameter-values-of-check_.patch

- agents: handle dampening parameter consistently and correctly
  * 0001-Fix-agents-handle-dampening-parameter-consistently-a.patch

- crm_resource: make --wait wait for pending actions in CIB
  * 0001-Refactor-crm_resource-make-wait-wait-for-pending-act.patch

- agents: HealthCPU - fix the validation of input
  * 0001-fix-the-validation-of-input.patch

Package protobuf was updated:

- update to 25.1:  * Raise warnings for deprecated python syntax usages
  * Add support for extensions in CRuby, JRuby, and FFI Ruby
  * Add support for options in CRuby, JRuby and FFI (#14594)
- update to 25.0:
  * Implement proto2/proto3 with editions
  * Defines Protobuf compiler version strings as macros and
    separates out suffix string definition.
  * Add utf8_validation feature back to the global feature set.
  * Setting up version updater to prepare for poison pills and
    embedding version info into C++, Python and Java gencode.
  * Merge the protobuf and upb Bazel repos
  * Editions: Introduce functionality to protoc for generating
    edition feature set defaults.
  * Editions: Migrate edition strings to enum in C++ code.
  * Create a reflection helper for ExtensionIdentifier.
  * Editions: Provide an API for C++ generators to specify their
    features.
  * Editions: Refactor feature resolution to use an intermediate
    message.
  * Publish extension declarations with declaration
    verifications.
  * Editions: Stop propagating partially resolved feature sets to
    plugins.
  * Editions: Migrate string_field_validation to a C++ feature
  * Editions: Include defaults for any features in the generated
    pool.
  * Protoc: parser rejects explicit use of map_entry option
  * Protoc: validate that reserved range start is before end
  * Protoc: support identifiers as reserved names in addition to
    string literals (only in editions)
  * Drop support for Bazel 5.
  * Allow code generators to specify whether or not they support
    editions.
  [#] C++
  * Set `PROTOBUF_EXPORT` on
    `InternalOutOfLineDeleteMessageLite()`
  * Update stale checked-in files
  * Apply PROTOBUF_NOINLINE to declarations of some functions
    that want it.
  * Implement proto2/proto3 with editions
  * Make JSON UTF-8 boundary check inclusive of the largest
    possible UTF-8 character.
  * Reduce `Map::size_type` to 32-bits. Protobuf containers can't
    have more than that
  * Defines Protobuf compiler version strings as macros and
    separates out suffix string definition.
  * Add `ABSL_ATTRIBUTE_LIFETIME_BOUND` attribute on generated
    oneof accessors.
  * Fix bug in reflection based Swap of map fields.
  * Add utf8_validation feature back to the global feature set.
  * Setting up version updater to prepare for poison pills and
    embedding version info into C++, Python and Java gencode.
  * Add prefetching to arena allocations.
  * Add `ABSL_ATTRIBUTE_LIFETIME_BOUND` attribute on generated
    repeated and map field accessors.
  * Editions: Migrate edition strings to enum in C++ code.
  * Create a reflection helper for ExtensionIdentifier.
  * Editions: Provide an API for C++ generators to specify their
    features.
  * Add `ABSL_ATTRIBUTE_LIFETIME_BOUND` attribute on generated
    string field accessors.
  * Editions: Refactor feature resolution to use an intermediate
    message.
  * Fixes for 32-bit MSVC.
  * Publish extension declarations with declaration
    verifications.
  * Export the constants in protobuf's any.h to support DLL
    builds.
  * Implement AbslStringify for the Descriptor family of types.
  * Add `ABSL_ATTRIBUTE_LIFETIME_BOUND` attribute on generated
    message field accessors.
  * Editions: Stop propagating partially resolved feature sets to
    plugins.
  * Editions: Migrate string_field_validation to a C++ feature
  * Editions: Include defaults for any features in the generated
    pool.
  * Introduce C++ feature for UTF8 validation.
  * Protoc: validate that reserved range start is before end
  * Remove option to disable the table-driven parser in protoc.
  * Lock down ctype=CORD in proto file.
  * Support split repeated fields.
  * In OSS mode omit some extern template specializations.
  * Allow code generators to specify whether or not they support
    editions.
  [#] Java
  * Implement proto2/proto3 with editions
  * Remove synthetic oneofs from Java gencode field accessor
    tables.
  * Timestamps.parse: Add error handling for invalid
    hours/minutes in the timezone offset.
  * Defines Protobuf compiler version strings as macros and
    separates out suffix string definition.
  * Add `ABSL_ATTRIBUTE_LIFETIME_BOUND` attribute on generated
    oneof accessors.
  * Add missing debugging version info to Protobuf Java gencode
    when multiple files are generated.
  * Fix a bad cast in putBuilderIfAbsent when already present due
    to using the result of put() directly (which is null if it
    currently has no value)
  * Setting up version updater to prepare for poison pills and
    embedding version info into C++, Python and Java gencode.
  * Fix a NPE in putBuilderIfAbsent due to using the result of
    put() directly (which is null if it currently has no value)
  * Update Kotlin compiler to escape package names
  * Add MapFieldBuilder and change codegen to generate it and the
    put{field}BuilderIfAbsent method.
  * Introduce recursion limit in Java text format parsing
  * Consider the protobuf.Any invalid if typeUrl.split(&amp;quot;/&amp;quot;)
    returns an empty array.
  * Mark `FieldDescriptor.hasOptionalKeyword()` as deprecated.
  * Fixed Python memory leak in map lookup.
  * Loosen upb for json name conflict check in proto2 between
    json name and field
  * Defines Protobuf compiler version strings as macros and
    separates out suffix string definition.
  * Add `ABSL_ATTRIBUTE_LIFETIME_BOUND` attribute on generated
    oneof accessors.
  * Ensure Timestamp.ToDatetime(tz) has correct offset
  * Do not check required field for upb python MergeFrom
  * Setting up version updater to prepare for poison pills and
    embedding version info into C++, Python and Java gencode.
  * Merge the protobuf and upb Bazel repos
  * Comparing a proto message with an object of unknown returns
    NotImplemented
  * Emit __slots__ in pyi output as a tuple rather than a list
    for --pyi_out.
  * Fix a bug that strips options from descriptor.proto in
    Python.
  * Raise warings for message.UnknownFields() usages and navigate
    to the new add
  * Add protobuf python keyword support in path for stub
    generator.
  * Add tuple support to set Struct
  * ### Python C-Extension (Default)
  * Comparing a proto message with an object of unknown returns
    NotImplemented
  * Check that ffi-compiler loads before using it to define
    tasks.
  [#] UPB (Python/PHP/Ruby C-Extension)
  * Include .inc files directly instead of through a filegroup
  * Loosen upb for json name conflict check in proto2 between
    json name and field
  * Add utf8_validation feature back to the global feature set.
  * Do not check required field for upb python MergeFrom
  * Merge the protobuf and upb Bazel repos
  * Added malloc_trim() calls to Python allocator so RSS will
    decrease when memory is freed
  * Upb: fix a Python memory leak in ByteSize()
  * Support ASAN detection on clang
  * Upb: bugfix for importing a proto3 enum from within a proto2
    file
  * Expose methods needed by Ruby FFI using UPB_API
  * Fix `PyUpb_Message_MergeInternal` segfault

- build against modern python on sle15

- Build with source and target levels 8
  * fixes build with JDK21
- Install the pom file with the new %%mvn_install_pom macro
- Do not install the pom-only artifacts, since the %%mvn_install_pom
  macro resolves the variables at the install time

- update to 23.4:
  * Add dllexport_decl for generated default instance.
  * Deps: Update Guava to 32.0.1

- update to 23.3:
  C++
  * Regenerate stale files
  * Use the same ABI for static and shared libraries on non-
    Windows platforms
  * Add a workaround for GCC constexpr bug
  Objective-C
  * Regenerate stale files
  UPB (Python/PHP/Ruby C-Extension)
  * Fixed a bug in `upb_Map_Delete()` that caused crashes in
    map.delete(k) for Ruby when string-keyed maps were in use.
  Compiler
  * Add missing header to Objective-c generator
  * Add a workaround for GCC constexpr bug
  Java
  * Rollback of: Simplify protobuf Java message builder by
    removing methods that calls the super class only.
  Csharp
  * [C#] Replace regex that validates descriptor names
- drop 0001-Use-the-same-ABI-for-static-and-shared-libraries-on-.patch (upstream)

- Add patch to fix linking ThreadSafeArena:
  * 0001-Use-the-same-ABI-for-static-and-shared-libraries-on-.patch
- Drop the protobuf-source package, no longer used

- update to 22.5:
  C++
  * Add missing cstdint header
  * Fix: missing -DPROTOBUF_USE_DLLS in pkg-config (#12700)
  * Avoid using string(JOIN..., which requires cmake 3.12
  * Explicitly include GTest package in examples
  * Bump Abseil submodule to 20230125.3 (#12660)
- update to 22.4:
  C++
  * Fix libprotoc: export useful symbols from .so
  * Fix btree issue in map tests.
  Python
  * Fix bug in _internal_copy_files where the rule would fail in
    downstream repositories.
  Other
  * Bump utf8_range to version with working pkg-config (#12584)
  * Fix declared dependencies for pkg-config
  * Update abseil dependency and reorder dependencies to ensure
    we use the version specified in protobuf_deps.
  * Turn off clang::musttail on i386

- drop python2 handling
- fix version handling and package the private libs again

- Fix confusion in versions

- Mention the rpmlintrc file in the spec.

- Make possible to build on older systems, like SLE12 that miss
  some of the used macros.

- update to v22.3
  UPB (Python/PHP/Ruby C-Extension)
  * Remove src prefix from proto import
  * Fix .gitmodules to use the correct absl branch
  * Remove erroneous dependency on googletest
- update to 22.2:
  Java
  * Add version to intra proto dependencies and add kotlin stdlib
    dependency
  * Add $ back for osgi header
  * Remove $ in pom files
- update to 22.1:
  * Add visibility of plugin.proto to python directory
  * Strip &amp;quot;src&amp;quot; from file name of plugin.proto
  * Add OSGi headers to pom files.
  * Remove errorprone dependency from kotlin protos.
  * Version protoc according to the compiler version number.
- update to 22.0:
  * This version includes breaking changes to: Cpp.
    Please refer to the migration guide for information:
    https://protobuf.dev/support/migration/#compiler-22
  * [Cpp] Migrate to Abseil's logging library.
  * [Cpp] `proto2::Map::value_type` changes to `std::pair`.
  * [Cpp] Mark final ZeroCopyInputStream, ZeroCopyOutputStream,
    and DefaultFieldComparator classes.
  * [Cpp] Add a dependency on Abseil (#10416)
  * [Cpp] Remove all autotools usage (#10132)
  * [Cpp] Add C++20 reserved keywords
  * [Cpp] Dropped C++11 Support
  * [Cpp] Delete Arena::Init
  * [Cpp] Replace JSON parser with new implementation
  * [Cpp] Make RepeatedField::GetArena non-const in order to
    support split RepeatedFields.
  * long list of bindings specific fixes see
    https://github.com/protocolbuffers/protobuf/releases/tag/v22.0
- python sub packages version is set 4.22.3 as defined in
  python/google/protobuf/__init__.py to stay compatible
- skip python2 builds by default
- drop patches:
  * 10355.patch,
  * gcc12-disable-__constinit-with-c++-11.patch (merged upstream)
- added patches:
  * add-missing-stdint-header.patch   added for compile fixes

- Enable LTO (boo#1133277).

- update to v21.12:
  * Python
  * Fix broken enum ranges (#11171)
  * Stop requiring extension fields to have a sythetic oneof (#11091)
  * Python runtime 4.21.10 not works generated code can not load valid
    proto.

- update to 21.11:
  * Python
  * Add license file to pypi wheels (#10936)
  * Fix round-trip bug (#10158)

- update to 21.10:
  * Java
  * Use bit-field int values in buildPartial to skip work on unset groups of
    fields. (#10960)
  * Mark nested builder as clean after clear is called (#10984)

- update to 21.9:
  * Ruby
  * Replace libc strdup usage with internal impl to restore musl compat (#10818)
  * Auto capitalize enums name in Ruby (#10454) (#10763)
  * Other
  * Fix for grpc.tools #17995 &amp;amp; protobuf #7474 (handle UTF-8 paths in argumentfile) (#10721)
  * C++
  * 21.x No longer define no_threadlocal on OpenBSD (#10743)
  * Java
  * Mark default instance as immutable first to avoid race during static initialization of default instances (#10771)
  * Refactoring java full runtime to reuse sub-message builders and prepare to
    migrate parsing logic from parse constructor to builder.
  * Move proto wireformat parsing functionality from the private &amp;quot;parsing
    constructor&amp;quot; to the Builder class.
  * Change the Lite runtime to prefer merging from the wireformat into mutable
    messages rather than building up a new immutable object before merging. This
    way results in fewer allocations and copy operations.
  * Make message-type extensions merge from wire-format instead of building up
    instances and merging afterwards. This has much better performance.
  * Fix TextFormat parser to build up recurring (but supposedly not repeated)
    sub-messages directly from text rather than building a new sub-message and
    merging the fully formed message into the existing field.

- update to 21.6:
  C++:
  * Reduce memory consumption of MessageSet parsing

- update to 21.5:
  PHP
  * Added getContainingOneof and getRealContainingOneof to descriptor.
  * fix PHP readonly legacy files for nested messages
  Python
  * Fixed comparison of maps in Python.

- add 10355.patch to fix soversioning

- update to 21.4:
  * Reduce the required alignment of ArenaString from 8 to 4

- update to 21.3:
  * C++
  * Add header search paths to Protobuf-C++.podspec (#10024)
  * Fixed Visual Studio constinit errors (#10232)
  * Fix #9947: make the ABI compatible between debug and non-debug builds (#10271)
  * UPB
  * Allow empty package names (fixes behavior regression in 4.21.0)
  * Fix a SEGV bug when comparing a non-materialized sub-message (#10208)
  * Fix several bugs in descriptor mapping containers (eg. descriptor.services_by_name)
  * for x in mapping now yields keys rather than values, to match Python
    conventions and the behavior of the old library.
  * Lookup operations now correctly reject unhashable types as map keys.
  * We implement repr() to use the same format as dict.
  * Fix maps to use the ScalarMapContainer class when appropriate
  * Fix bug when parsing an unknown value in a proto2 enum extension (protocolbuffers/upb#717)
  * PHP
  * Add &amp;quot;readonly&amp;quot; as a keyword for PHP and add previous classnames to descriptor pool (#10041)
  * Python
  * Make //:protobuf_python and //:well_known_types_py_pb2 public (#10118)
  * Bazel
  * Add back a filegroup for :well_known_protos (#10061)

- Update to 21.2:
- C++
  - cmake: Call get_filename_component() with DIRECTORY mode instead of PATH mode (#9614)
  - Escape GetObject macro inside protoc-generated code (#9739)
  - Update CMake configuration to add a dependency on Abseil (#9793)
  - Fix cmake install targets (#9822)
  - Use __constinit only in GCC 12.2 and up (#9936)
- Java
  - Update protobuf_version.bzl to separate protoc and per-language java â¦ (#9900)
- Python
  - Increment python major version to 4 in version.json for python upb (#9926)
  - The C extension module for Python has been rewritten to use the upb library.
  - This is expected to deliver significant performance benefits, especially when
    parsing large payloads. There are some minor breaking changes, but these
    should not impact most users. For more information see:
    https://developers.google.com/protocol-buffers/docs/news/2022-05-06#python-updates
- PHP
  - [PHP] fix PHP build system (#9571)
  - Fix building packaged PHP extension (#9727)
  - fix: reserve &amp;quot;ReadOnly&amp;quot; keyword for PHP 8.1 and add compatibility (#9633)
  - fix: phpdoc syntax for repeatedfield parameters (#9784)
  - fix: phpdoc for repeatedfield (#9783)
  - Change enum string name for reserved words (#9780)
  - chore: [PHP] fix phpdoc for MapField keys (#9536)
  - Fixed PHP SEGV by not writing to shared memory for zend_class_entry. (#9996)
- Ruby
  - Allow pre-compiled binaries for ruby 3.1.0 (#9566)
  - Implement respond_to? in RubyMessage (#9677)
  - [Ruby] Fix RepeatedField#last, #first inconsistencies (#9722)
  - Do not use range based UTF-8 validation in truffleruby (#9769)
  - Improve range handling logic of RepeatedField (#9799)
- Other
  - Fix invalid dependency manifest when using descriptor_set_out (#9647)
  - Remove duplicate java generated code (#9909)

- Do not use %%autosetup, but %%setup and %%patch on other line
  * Allows building on SLE-12-SP5

- Add temporary patch gcc12-disable-__constinit-with-c++-11.patch
  that addresses gh#protocolbuffers/protobuf#9916.

Package python3 was updated:

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

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

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

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

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

- Refresh CVE-2023-27043-email-parsing-errors.patch to
  gh#python/cpython!111116, fixing bsc#1210638 (CVE-2023-27043).

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]

- build for multiple python versions [jsc#PED-6218]
- bump version to 0.7.28

Package libssh was updated:

- Fix regression parsing IPv6 addresses provided as hostname (bsc#1220385)  * Added libssh-fix-ipv6-hostname-regression.patch

Package libssh2_org was updated:

- Fix an issue with Encrypt-then-MAC family. [bsc#1221622]  * Test the ETM feature in the remote end's configuration when
    receiving data. Upstream issue: #1331.
  * Add libssh2_org-ETM-remote.patch

- Always add the KEX pseudo-methods &amp;quot;ext-info-c&amp;quot; and &amp;quot;kex-strict-c-v00@openssh.com&amp;quot;
  when configuring custom method list. [bsc#1218971, CVE-2023-48795]
  * The strict-kex extension is announced in the list of available
    KEX methods. However, when the default KEX method list is modified
    or replaced, the extension is not added back automatically.
  * Add libssh2_org-CVE-2023-48795-ext.patch

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

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

- Update to version 1.8.0
  * Allow &amp;quot;--rollback&amp;quot; flag to run on readonly filesystem (bsc#1220679)

- Update to version 1.7.0
  * Allow SUSEConnect on read write transactional systems (bsc#1219425)

Package tiff was updated:

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

- security update:
  * CVE-2023-40745[bsc#1214687] CVE-2023-41175[bsc#1214686] [bsc#1221187]
    CVE-2023-38288[bsc#1213590]
    Fix potential int overflow in raw2tiff.c and tiffcp.c
    Rename tiff-CVE-2023-38288.patch into
    tiff-CVE-2023-38288,CVE-2023-40745,CVE-2023-41175.patch

- security update:
  * CVE-2023-52356 [bsc#1219213]
    Fix segfault in TIFFReadRGBATileExt()
    + tiff-CVE-2023-52356.patch

Package libvirt was updated:

- node_device_conf: Avoid memleak in virNodeDeviceGetPCIVPDDynamicCap()  64d32118-fix-nodedev-memleak.patch
  bsc#1221749

- CVE-2024-2494: remote: check for negative array lengths before
  allocation
  8a3f8d95-CVE-2024-2494.patch
  bsc#1221815

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

- Security fix (CVE-2024-25062, bsc#1219576) use-after-free in XMLReader
  * Added libxml2-CVE-2024-25062.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)

- Don't try to refresh volatile media as long as raw metadata are
  present (bsc#1223094)
- version 17.32.5 (32)

- Fix creation of sibling cache dirs with too restrictive mode
  (bsc#1222398)
  Some install workflows in YAST may lead to too restrictive (0700)
  raw cache directories in case of newly created repos. Later
  commands running with user privileges may not be able to access
  these repos.
- version 17.32.4 (32)

- Update RepoStatus fromCookieFile according to the files mtime
  (bsc#1222086)
- TmpFile: Don't call chmod if makeSibling failed.
- version 17.32.3 (32)

- Fixup New VendorSupportOption flag VendorSupportSuperseded
  (jsc#OBS-301, jsc#PED-8014)
  Fixed the name of the keyword to &amp;quot;support_superseded&amp;quot; as it was
  agreed on in jsc#OBS-301.
- version 17.32.2 (32)

- Add resolver option 'removeUnneeded' to file weak remove jobs
  for unneeded packages (bsc#1175678)
- version 17.32.1 (32)

- Add resolver option 'removeOrphaned' for distupgrade
  (bsc#1221525)
- New VendorSupportOption flag VendorSupportSuperseded
  (jsc#OBS-301, jsc#PED-8014)
- Tests: fix vsftpd.conf where SUSE and Fedora use different
  defaults (fixes #522)
- Add default stripe minimum (#529)
- Don't expose std::optional where YAST/PK explicitly use c++11.
- Digest: Avoid using the deprecated OPENSSL_config.
- version 17.32.0 (32)

- ProblemSolution::skipsPatchesOnly overload to handout the
  patches.
- Remove https-&amp;gt;http redirection exceptions for
  download.opensuse.org.
- version 17.31.32 (22)

- tui: allow to access the underlying ostream of out::Info.
- Add MLSep: Helper to produce not-NL-terminated multi line
  output.
- version 17.31.31 (22)

- applydeltaprm: Create target directory if it does not exist
  (bsc#1219442)
- Add ProblemSolution::skipsPatchesOnly (for openSUSE/zypper#514)
- Fix problems with EINTR in ExternalDataSource::getline (fixes
  bsc#1215698)
- version 17.31.30 (22)

- CheckAccessDeleted: fix running_in_container detection
  (bsc#1218782)
- Detect CURLOPT_REDIR_PROTOCOLS_STR availability at runtime
  (bsc#1218831)
- Make Wakeup class EINTR safe.
- Add a way to cancel media operations on shutdown
  (openSUSE/zypper#522)
  This patch adds a mechanism to signal libzypp that a shutdown was
  requested, usually when CTRL+C was pressed by the user. Currently
  only the media backend will utilize this, but can be extended to
  all code paths that use g_poll() to wait for events.
- Manually poll fds for curl in MediaCurl.
  Using curl_easy_perform does not give us the required control on
  when we want to cancel a download. Switching to the MultiCurl
  implementation with a external poll() event loop will give us
  much more freedom and helps us to improve our Ctrl+C handling.
- Move reusable curl poll code to curlhelper.h.
- version 17.31.29 (22)

- Fix to build with libxml 2.12.x (fixes #505)
- version 17.31.28 (22)

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

- bsc#1176006: Fix chage date miscalculation
  Add shadow-bsc1176006-chage-date.patch
- bsc#1188307: Fix passwd segfault
  Add shadow-bsc1188307-passwd-segfault.patch
- bsc#1203823: Remove pam_keyinit from PAM config files
  Remove pam_keyinit from PAM configuration.
  This was introduced for bsc#1144060.

Package netcfg was updated:

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

- fsck.ocfs2: add the ability to clear jbd2 errno (bsc#1216834)
  + bsc1216834-fsck.ocfs2-add-the-ability-to-clear-jbd2-errno.patch

Package opensc was updated:

- Security fix: [CVE-2023-5992, bsc#1219386]  * Add patch:
  - opensc-CVE-2023-5992.patch

Package openssh was updated:

- Add patches from upstream to change the default value of  UpdateHostKeys to Yes (unless VerifyHostKeyDNS is enabled).
  This makes ssh update the known_hosts stored keys with all
  published versions by the server (after it's authenticated
  with an existing key), which will allow to identify the
  server with a different key if the existing key is considered
  insecure at some point in the future (bsc#1222831).
  * 0001-upstream-enable-UpdateHostkeys-by-default-when-the.patch
  * 0002-upstream-disable-UpdateHostkeys-by-default-if.patch

- Add patches openssh-7.7p1-seccomp_getuid.patch and
  openssh-bsc1216474-s390-leave-fds-open.patch
  (bsc#1216474, bsc#1218871)

- Fix hostbased ssh login failing occasionally with &amp;quot;signature
  unverified: incorrect signature&amp;quot; by fixing a typo in patch
  (bsc#1221123):
  * openssh-7.8p1-role-mls.patch

- Added openssh-cve-2023-51385.patch (bsc#1218215, CVE-2023-51385).
  This limits the use of shell metacharacters in host- and
  user names.

Package pam-config was updated:

- Fix pam_gnome_keyring module for AUTH.  [pam-config-fix-pam_gnome_keyring.patch, bsc#1219767]

Package pam_pkcs11 was updated:

- Fix for bsc#1221255:  * Add patch 0001-Set-slot_num-configuration-parameter-to-0-by-default.patch

Package patterns-base was updated:

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

Package perl-Bootloader was updated:

- merge gh#openSUSE/perl-bootloader#166- log grub2-install errors correctly (bsc#1221470)
- 0.947

- merge gh#openSUSE/perl-bootloader#161
- support old grub versions (&amp;lt;= 2.02) that used /usr/lib
  (bsc#1218842)
- create EFI boot fallback directory if necessary
- 0.946

Package perl was updated:

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

Package python-Jinja2 was updated:

- Add CVE-2024-34064.patch upstream patch  (CVE-2024-34064, bsc#1223980, gh#pallets/jinja@0668239dc6b4)
  Also fixes (CVE-2024-22195, bsc#1218722)

Package python-idna was updated:

- Add CVE-2024-3651.patch, backported from upstream commit  gh#kjd/idna#172/commits/5beb28b9dd77912c0dd656d8b0fdba3eb80222e7
  (bsc#1222842, CVE-2024-3651)

Package python-pycryptodome was updated:

- Add CVE-2023-52323-side_channel-RSA_decrypt.patch (bsc#1218564,  CVE-2023-52323) fixing side-channel leakage in RSA decryption.
- Add CVE-2023-52323-const_time-decoding.patch (bsc#1218564,
  CVE-2023-52323) using constant-time (faster) padding decoding
  also for OAEP.

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

- Speed up salt.matcher.confirm_top by using __context__- Do not call the async wrapper calls with the separate thread
- Prevent OOM with high amount of batch async calls (bsc#1216063)
- Add missing contextvars dependency in salt.version
- Skip tests for unsupported algorithm on old OpenSSL version
- Remove redundant `_file_find` call to the master
- Prevent possible exception in tornado.concurrent.Future._set_done
- Make reactor engine less blocking the EventPublisher
- Make salt-master self recoverable on killing EventPublisher
- Improve broken events catching and reporting
- Make logging calls lighter
- Remove unused import causing delays on starting salt-master
- Mark python3-CherryPy as recommended package for the testsuite
- Added:
  * make-salt-master-self-recoverable-on-killing-eventpu.patch
  * skip-tests-for-unsupported-algorithm-on-old-openssl-.patch
  * remove-redundant-_file_find-call-to-the-master.patch
  * prevent-possible-exception-in-tornado.concurrent.fut.patch
  * improve-broken-events-catching-and-reporting.patch
  * add-missing-contextvars-dependency-in-salt.version.patch
  * do-not-call-the-async-wrapper-calls-with-the-separat.patch
  * make-logging-calls-lighter.patch
  * make-reactor-engine-less-blocking-the-eventpublisher.patch
  * speed-up-salt.matcher.confirm_top-by-using-__context.patch
  * remove-unused-import-causing-delays-on-starting-salt.patch
  * prevent-oom-with-high-amount-of-batch-async-calls-bs.patch

- Make &amp;quot;man&amp;quot; a recommended package instead of required

- Convert oscap output to UTF-8
- Make Salt compatible with Python 3.11
- Ignore non-ascii chars in oscap output (bsc#1219001)
- Fix detected issues in Salt tests when running on VMs
- Make importing seco.range thread safe (bsc#1211649)
- Fix problematic tests and allow smooth tests executions
  on containers
- Discover Ansible playbook files as &amp;quot;*.yml&amp;quot; or &amp;quot;*.yaml&amp;quot;
  files (bsc#1211888)
- Provide user(salt)/group(salt) capabilities for RPM 4.19
- Extend dependencies for python3-salt-testsuite
  and python3-salt packages
- Improve Salt and testsuite packages multibuild
- Enable multibuilld and create test flavor
- Prevent exceptions with fileserver.update when called
  via state (bsc#1218482)
- Improve pip target override condition with VENV_PIP_TARGET
  environment variable (bsc#1216850)
- Fixed KeyError in logs when running a state that fails
- Added:
  * fixed-keyerror-in-logs-when-running-a-state-that-fai.patch
  * decode-oscap-byte-stream-to-string-bsc-1219001.patch
  * fix-salt-warnings-and-testuite-for-python-3.11-635.patch
  * make-importing-seco.range-thread-safe-bsc-1211649.patch
  * improve-pip-target-override-condition-with-venv_pip_.patch
  * allow-kwargs-for-fileserver-roots-update-bsc-1218482.patch
  * fix-problematic-tests-and-allow-smooth-tests-executi.patch
  * discover-both-.yml-and-.yaml-playbooks-bsc-1211888.patch
  * fix-tests-failures-and-errors-when-detected-on-vm-ex.patch
  * switch-oscap-encoding-to-utf-8-639.patch

- Prevent directory traversal when creating syndic cache directory
  on the master (CVE-2024-22231, bsc#1219430)
- Prevent directory traversal attacks in the master's serve_file
  method (CVE-2024-22232, bsc#1219431)
- Added:
  * fix-cve-2024-22231-and-cve-2024-22232-bsc-1219430-bs.patch

- Ensure that pillar refresh loads beacons from pillar without restart
- Fix the aptpkg.py unit test failure
- Prefer unittest.mock to python-mock in test suite
- Enable &amp;quot;KeepAlive&amp;quot; probes for Salt SSH executions (bsc#1211649)
- Revert changes to set Salt configured user early in the stack (bsc#1216284)
- Align behavior of some modules when using salt-call via symlink (bsc#1215963)
- Fix gitfs &amp;quot;__env__&amp;quot; and improve cache cleaning (bsc#1193948)
- Remove python-boto dependency for the python3-salt-testsuite package for Tumbleweed
- Added:
  * fix-the-aptpkg.py-unit-test-failure.patch
  * enable-keepalive-probes-for-salt-ssh-executions-bsc-.patch
  * prefer-unittest.mock-for-python-versions-that-are-su.patch
  * update-__pillar__-during-pillar_refresh.patch
  * revert-make-sure-configured-user-is-properly-set-by-.patch
  * fix-gitfs-__env__-and-improve-cache-cleaning-bsc-119.patch
  * dereference-symlinks-to-set-proper-__cli-opt-bsc-121.patch

Package python-urllib3 was updated:

Package rpm-ndb was updated:

Package rubygem-rack was updated:

- security update- added patches
  fix CVE-2024-25126 [bsc#1220239], Denial of Service Vulnerability in Rack Content-Type Parsing
  + rubygem-rack-CVE-2024-25126.patch
  fix CVE-2024-26141 [bsc#1220242], Denial of Service Vulnerability in Range request header parsing
  + rubygem-rack-CVE-2024-26141.patch
  fix CVE-2024-26146 [bsc#1220248], Denial of Service vulnerability in Rack headers parsing routine
  + rubygem-rack-CVE-2024-26146.patch

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

- Add upstream patch &amp;lt;https://github.com/opencontainers/runc/pull/4219&amp;gt; to
  properly fix -ENOSYS stub on ppc64le. bsc#1192051 bsc#1221050
  + 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

- Update to runc v1.1.12. Upstream changelog is available from
  &amp;lt;https://github.com/opencontainers/runc/releases/tag/v1.1.12&amp;gt;. bsc#1218894
  * This release fixes a container breakout vulnerability (CVE-2024-21626). For
    more details, see the upstream security advisory:
    &amp;lt;https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv&amp;gt;
  * Remove upstreamed patches:
  - CVE-2024-21626.patch
  * Update runc.keyring to match upstream changes.

Package sapconf was updated:

- add require of package sysctl-logger for 15SP4 and 15SP5 too  (jsc#PED-6220)

- version update from 5.0.6 to 5.0.7
- add require of package sysctl-logger for 15SP6
  (jsc#PED-5025)
- suppress error message regarding missing systemd service file
  during posttrans script

Package saptune was updated:

- add require of package sysctl-logger for 15SP4 and 15SP5 too  (jsc#PED-6220)

- update package version of saptune to 3.1.2
  * to support setups with saptune monitoring and heavy automation
    we limited the setting of our saptune lock to commands having
    the potential to change anything in the system.
    (bsc#1219500)
  * fix timestamp in log messages of saptune
  * remove redundant version information in header comment of
    note definition files
  * SAP Note 1656250 updated to Version 63
    SAP Note 1771258 updated to Version 8
    SAP Note 2382421 updated to Version 45
    SAP Note 3024346 updated to Version 10
    but without parameter value changes, only house keeping of the
    version section and comment updates
  * SAP Note 1984787 updated to Version 42
    SAP Note 2578899 updated to Version 47
- add require of package sysctl-logger for 15SP6
  (jsc#PED-5025)

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

- updated to 0.1.71 (jsc#ECO-3319)
  - Add RHEL 9 STIG
  - Add support for Debian 12
  - Update PCI-DSS profile for RHEL
  - lots of bugfixes and improvements for SLE
- removed left over file
  0001-Revert-fix-aide-remediations-add-crontabs.patch upstreamed in 0.1.69

Package sed was updated:

- 0001-sed-set-correct-umask-on-temporary-files.patch  Fix for bsc#1221218

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-public-cloud-release was updated:

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

Package 000release-packages:sle-module-server-applications-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 sudo was updated:

- Fix NOPASSWD issue introduced by patches for CVE-2023-42465  [bsc#1221151, bsc#1221134]
  * Update sudo-CVE-2023-42465-1of2.patch sudo-CVE-2023-42465-2of2.patch
  * Enable running regression selftests during build time.

- Security fix: [bsc#1219026, bsc#1220389, CVE-2023-42465]
  * Try to make sudo less vulnerable to ROWHAMMER attacks.
  * Add sudo-CVE-2023-42465-1of2.patch sudo-CVE-2023-42465-2of2.patch

Package supportutils-plugin-ha-sap was updated:

- Update to version 0.0.5+git.1709295499.1c8e8cd  * adapt documentation links
  * add support for SAP systemd services regarding SID retrieval
  * add information about SAP related systemd services
  * add information about sapcontrol function GetStartProfile
  * add information from daemon.ini
  * collect hook script logs (suschksrv and saphanasr_multitarget_hook)
  * collect logs of sap_suse_cluster_connector and sapstartsrv
  * Add python version
  * Check sudoers for srhook configuration

Package supportutils-plugin-suse-public-cloud was updated:

- Update to version 1.0.9 (bsc#1218762, bsc#1218763)  + Remove duplicate data collection for the plugin itself
  + Collect archive metering data when available
  + Query billing flavor status

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)

- Changes to version 3.1.29
  + Extended scaling for performance (bsc#1214713)
  + Fixed kdumptool output error (bsc#1218632)
  + Corrected podman ID errors (bsc#1218812)
  + Duplicate non root podman entries removed (bsc#1218814)
  + Corrected get_sles_ver for SLE Micro (bsc#1219241)
  + Check nvidida-persistenced state (bsc#1219639)

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.

- Switch container key to be default RSA 4096bit. (jsc#PED-2777)

- run rpm commands in import script only when libzypp is not
  active. bsc#1219189 bsc#1219123

- run import script also in %posttrans section, but only when
  libzypp is not active. bsc#1219189 bsc#1219123

Package systemd-default-settings was updated:

- Import 0.10  5088997 SLE: Disable pids controller limit under user instances (jsc#SLE-10123)

- Import 0.9
  bb859bf user@.service: Disable controllers by default (jsc#PED-2276)

- The usage of drop-ins is now the official way for configuring systemd and its
  various daemons on Factory/ALP. Hence the early drop-ins SUSE specific
  &amp;quot;feature&amp;quot; has been abandoned.

- Import 0.8
  f34372f User priority '26' for SLE-Micro
  c8b6f0a Revert &amp;quot;Convert more drop-ins into early ones&amp;quot;

- Import commit 6b8dde1d4f867aff713af6d6830510a84fad58d2
  6b8dde1 Convert more drop-ins into early ones

Package systemd-presets-branding-SLE was updated:

Package systemd-presets-common-SUSE was updated:

- Split hcn-init.service to hcn-init-NetworkManager and hcn-init-wicked  (bsc#1200731 ltc#198485 https://github.com/ibm-power-utilities/powerpc-utils/pull/84)
  Support both the old and new service to avoid complex version interdependency.

Package systemd-rpm-macros was updated:

- Bump version to 15
- Order packages that requires systemd after systemd-sysvcompat when this part
  of the transaction (bsc#1217964)
  systemd-sysvcompat has been introduced recently and contains the compatibility
  scripts used to support SysV init scripts. Make sure that the packages ordered
  after systemd are also ordered after systemd-sysvcompat so theirs rpm
  scriptlets can still rely on the compat scripts.
  On distributions where systemd-sysvcompat doesn't exist, the new ordering
  constraint should be a nop.

Package timezone was updated:

- update to 2024a:  * Kazakhstan unifies on UTC+5.  This affects Asia/Almaty and
    Asia/Qostanay which together represent the eastern portion of the
    country that will transition from UTC+6 on 2024-03-01 at 00:00 to
    join the western portion.  (Thanks to Zhanbolat Raimbekov.)
  * Palestine springs forward a week later than previously predicted
    in 2024 and 2025.  (Thanks to Heba Hamad.)  Change spring-forward
    predictions to the second Saturday after Ramadan, not the first;
    this also affects other predictions starting in 2039.
  * Asia/Ho_Chi_Minh's 1955-07-01 transition occurred at 01:00
    not 00:00.  (Thanks to ÄoÃ n Tráº§n CÃ´ng Danh.)
  * From 1947 through 1949, Toronto's transitions occurred at 02:00
    not 00:00.  (Thanks to Chris Walton.)
  * In 1911 Miquelon adopted standard time on June 15, not May 15.
  * The FROM and TO columns of Rule lines can no longer be &amp;quot;minimum&amp;quot;
    or an abbreviation of &amp;quot;minimum&amp;quot;, because TZif files do not support
    DST rules that extend into the indefinite past - although these
    rules were supported when TZif files had only 32-bit data, this
    stopped working when 64-bit TZif files were introduced in 1995.
    This should not be a problem for realistic data, since DST was
    first used in the 20th century.  As a transition aid, FROM columns
    like &amp;quot;minimum&amp;quot; are now diagnosed and then treated as if they were
    the year 1900; this should suffice for TZif files on old systems
    with only 32-bit time_t, and it is more compatible with bugs in
    2023c-and-earlier localtime.c.  (Problem reported by Yoshito
    Umaoka.)
  * localtime and related functions no longer mishandle some
    timestamps that occur about 400 years after a switch to a time
    zone with a DST schedule.  In 2023d data this problem was visible
    for some timestamps in November 2422, November 2822, etc. in
    America/Ciudad_Juarez.  (Problem reported by Gilmore Davidson.)
  * strftime %s now uses tm_gmtoff if available.  (Problem and draft
    patch reported by Dag-Erling SmÃ¸rgrav.)
  * The strftime man page documents which struct tm members affect
    which conversion specs, and that tzset is called.  (Problems
    reported by Robert Elz and Steve Summit.)

- update to 2023d:
  * Ittoqqortoormiit, Greenland changes time zones on
    2024-03-31.
  * Vostok, Antarctica changed time zones on 2023-12-18.
  * Casey, Antarctica changed time zones five times since
    2020.
  * Code and data fixes for Palestine timestamps starting in
    2072.
  * A new data file zonenow.tab for timestamps starting now.
  * Fix predictions for DST transitions in Palestine in
    2072-2075, correcting a typo introduced in 2023a.
  * Vostok, Antarctica changed to +05 on 2023-12-18.  It had
    been at +07 (not +06) for years.
  * Change data for Casey, Antarctica to agree with
    timeanddate.com, by adding five time zone changes since 2020.
    Casey is now at +08 instead of +11.
  * Much of Greenland, represented by America/Nuuk, changed
    its standard time from -03 to -02 on 2023-03-25, not on
    2023-10-28.
  * localtime.c no longer mishandles TZif files that contain
    a single transition into a DST regime.  Previously,
    it incorrectly assumed DST was in effect before the transition
    too.
  * tzselect no longer creates temporary files.
  * tzselect no longer mishandles the following:
  * Spaces and most other special characters in BUGEMAIL,
    PACKAGE, TZDIR, and VERSION.
  * TZ strings when using mawk 1.4.3, which mishandles
    regular expressions of the form /X{2,}/.
  * ISO 6709 coordinates when using an awk that lacks the
    GNU extension of newlines in -v option-arguments.
  * Non UTF-8 locales when using an iconv command that
    lacks the GNU //TRANSLIT extension.
  * zic no longer mishandles data for Palestine after the
    year 2075.
- Refresh tzdata-china.diff

Package util-linux-systemd was updated:

- Properly neutralize escape sequences in wall  (util-linux-CVE-2024-28085.patch, bsc#1221831, CVE-2024-28085,
  and its prerequisites: util-linux-fputs_careful1.patch,
  util-linux-wall-migrate-to-memstream.patch
  util-linux-fputs_careful2.patch).

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

- Add upstream patch
  util-linux-libuuid-avoid-truncate-clocks.txt-to-improve-perform.patch
  bsc#1207987 gh#util-linux/util-linux@1d98827edde4

Package vim was updated:

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

- Updated to version 9.1 with patch level 0111, fixes the following security problems
  * Fixing bsc#1217316 (CVE-2023-48231) - VUL-0: CVE-2023-48231: vim: Use-After-Free in win_close()
  * Fixing bsc#1217320 (CVE-2023-48232) - VUL-0: CVE-2023-48232: vim: Floating point Exception in adjust_plines_for_skipcol()
  * Fixing bsc#1217321 (CVE-2023-48233) - VUL-0: CVE-2023-48233: vim: overflow with count for :s command
  * Fixing bsc#1217324 (CVE-2023-48234) - VUL-0: CVE-2023-48234: vim: overflow in nv_z_get_count
  * Fixing bsc#1217326 (CVE-2023-48235) - VUL-0: CVE-2023-48235: vim: overflow in ex address parsing
  * Fixing bsc#1217329 (CVE-2023-48236) - VUL-0: CVE-2023-48236: vim: overflow in get_number
  * Fixing bsc#1217330 (CVE-2023-48237) - VUL-0: CVE-2023-48237: vim: overflow in shift_line
  * Fixing bsc#1217432 (CVE-2023-48706) - VUL-0: CVE-2023-48706: vim: heap-use-after-free in ex_substitute
  * Fixing bsc#1219581 (CVE-2024-22667) - VUL-0: CVE-2024-22667: vim: stack-based buffer overflow in did_set_langmap function in map.c
  * Fixing bsc#1215005 (CVE-2023-4750) - VUL-0: CVE-2023-4750: vim: Heap use-after-free in function bt_quickfix
- for the complete list of changes see
  https://github.com/vim/vim/compare/v9.0.2103...v9.1.0111

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]

- client: do not convert sec to msec twice (bsc#1222105)
  [+ 0005-client-do-to-not-convert-sec-to-msec-twice-bsc-1222105.patch]

- addrconf: fix fallback-lease drop (bsc#1220996)
  [+ 0001-addrconf-fix-fallback-lease-drop-bsc-1220996.patch]
- extensions/nbft: use upstream `nvme nbft show` (bsc#1221358)
  [+ 0002-extensions-nbft-replace-nvme-show-nbft-with-nvme-nbf.patch]
- hide secrets in debug log (bsc#1221194)
  [+ 0003-move-all-attribute-definitions-to-compiler-h.patch]
  [+ 0004-hide-secrets-in-debug-log-bsc-1221194.patch]

- update to version 0.6.74
  + team: add new options like link_watch_policy (jsc#PED-7183)
  + Fix memory leaks in dbus variant destroy and fsm free (gh#openSUSE/wicked#1001)
  + xpath: allow underscore in node identifier (gh#openSUSE/wicked#999)
  + vxlan: don't format unknown rtnl attrs (bsc#1219751)
- removed patches included in the source archive:
  [- 0009-ifreload-VLAN-changes-require-device-deletion-bsc-12.patch]
  [- 0008-ifcheck-fix-config-changed-check-bsc-1218926.patch]
  [- 0007-Fix-ifstatus-exit-code-for-NI_WICKED_ST_NO_CARRIER-s.patch]
  [- 0006-dhcp6-omit-the-SO_REUSEPORT-option-bsc-1215692.patch]
  [- 0005-duid-fix-comment-for-v6time.patch]
  [- 0004-rtnl-parse-peer-address-on-non-ptp-interfaces.patch]
  [- 0003-rtnl-pass-ifname-in-newaddr-parsing-and-logging.patch]
  [- 0002-system-updater-Parse-updater-format-from-XML-configu.patch]
  [- 0001-fix_arp_notify_loop_and_burst_sending.patch]

- ifreload: VLAN changes require device deletion (bsc#1218927)
  [+ 0009-ifreload-VLAN-changes-require-device-deletion-bsc-12.patch]
- ifcheck: fix config changed check (bsc#1218926)
  [+ 0008-ifcheck-fix-config-changed-check-bsc-1218926.patch]
- client: fix exit code for no-carrier status (bsc#1219265)
  [+ 0007-Fix-ifstatus-exit-code-for-NI_WICKED_ST_NO_CARRIER-s.patch]
- dhcp6: omit the SO_REUSEPORT option (bsc#1215692)
  [+ 0006-dhcp6-omit-the-SO_REUSEPORT-option-bsc-1215692.patch]
- duid: fix comment for v6time
  (https://github.com/openSUSE/wicked/pull/989)
  [+ 0005-duid-fix-comment-for-v6time.patch]
- rtnl: fix peer address parsing for non ptp-interfaces
  (https://github.com/openSUSE/wicked/pull/987,
  https://github.com/openSUSE/wicked/pull/988)
  [+ 0003-rtnl-pass-ifname-in-newaddr-parsing-and-logging.patch]
  [+ 0004-rtnl-parse-peer-address-on-non-ptp-interfaces.patch]
- system-updater: Parse updater format from XML configuration to
  ensure install calls can run.
  (https://github.com/openSUSE/wicked/pull/985)
  [+ 0002-system-updater-Parse-updater-format-from-XML-configu.patch]

Package xen was updated:

- Update to Xen 4.16.6 security bug fix release (bsc#1027519)  xen-4.16.6-testing-src.tar.bz2
  * No upstream changelog found in sources or webpage
- bsc#1221984 - VUL-0: CVE-2023-46842: xen: x86 HVM hypercalls may
  trigger Xen bug check (XSA-454)
- bsc#1222302 - VUL-0: CVE-2024-31142: xen: x86: Incorrect logic
  for BTC/SRSO mitigations (XSA-455)
- bsc#1222453 - VUL-0: CVE-2024-2201: xen: x86: Native Branch
  History Injection (XSA-456)
- Dropped patches contained in new tarball
  64e5b4ac-x86-AMD-extend-Zenbleed-check.patch
  64e6459b-revert-VMX-sanitize-rIP-before-reentering.patch
  64eef7e9-x86-reporting-spurious-i8259-interrupts.patch
  64f71f50-Arm-handle-cache-flush-at-top.patch
  65087000-x86-spec-ctrl-SPEC_CTRL_EXIT_TO_XEN-confusion.patch
  65087001-x86-spec-ctrl-fold-DO_SPEC_CTRL_EXIT_TO_XEN.patch
  65087002-x86-spec-ctrl-SPEC_CTRL-ENTRY-EXIT-asm-macros.patch
  65087003-x86-spec-ctrl-SPEC_CTRL-ENTER-EXIT-comments.patch
  65087004-x86-entry-restore_all_xen-stack_end.patch
  65087005-x86-entry-track-IST-ness-of-entry.patch
  65087006-x86-spec-ctrl-VERW-on-IST-exit-to-Xen.patch
  65087007-x86-AMD-Zen-1-2-predicates.patch
  65087008-x86-spec-ctrl-Zen1-DIV-leakage.patch
  650abbfe-x86-shadow-defer-PV-top-level-release.patch
  65263470-AMD-IOMMU-flush-TLB-when-flushing-DTE.patch
  65263471-libfsimage-xfs-remove-dead-code.patch
  65263472-libfsimage-xfs-amend-mask32lo.patch
  65263473-libfsimage-xfs-sanity-check-superblock.patch
  65263474-libfsimage-xfs-compile-time-check.patch
  65263475-pygrub-remove-unnecessary-hypercall.patch
  65263476-pygrub-small-refactors.patch
  65263477-pygrub-open-output-files-earlier.patch
  65263478-libfsimage-function-to-preload-plugins.patch
  65263479-pygrub-deprivilege.patch
  6526347a-libxl-allow-bootloader-restricted-mode.patch
  6526347b-libxl-limit-bootloader-when-restricted.patch
  6526347c-SVM-fix-AMD-DR-MASK-context-switch-asymmetry.patch
  6526347d-x86-PV-auditing-of-guest-breakpoints.patch
  65536847-AMD-IOMMU-correct-level-for-quarantine-pt.patch
  65536848-x86-spec-ctrl-remove-conditional-IRQs-on-ness.patch
  xsa440.patch
  xsa449.patch
  xsa451.patch
  xsa452-1.patch
  xsa452-2.patch
  xsa452-3.patch
  xsa452-4.patch
  xsa452-5.patch
  xsa452-6.patch
  xsa452-7.patch
  xsa453-1.patch
  xsa453-2.patch
  xsa453-3.patch
  xsa453-4.patch
  xsa453-5.patch
  xsa453-6.patch
  xsa453-7.patch
  xsa453-8.patch
  xsa454-1.patch
  xsa454-2.patch

- bsc#1221332 - VUL-0: CVE-2023-28746: xen: x86: Register File Data
  Sampling (XSA-452)
  xsa452-1.patch
  xsa452-2.patch
  xsa452-3.patch
  xsa452-4.patch
  xsa452-5.patch
  xsa452-6.patch
  xsa452-7.patch
- bsc#1221334 - VUL-0: CVE-2024-2193: xen: GhostRace: Speculative
  Race Conditions (XSA-453)
  xsa453-1.patch
  xsa453-2.patch
  xsa453-3.patch
  xsa453-4.patch
  xsa453-5.patch
  xsa453-6.patch
  xsa453-7.patch
  xsa453-8.patch

- bsc#1219885 - VUL-0: CVE-2023-46841: xen: x86: shadow stack vs
  exceptions from emulation stubs (XSA-451)
  xsa451.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 xterm was updated:

- xterm-reset-parsing-state.patch: A bug in the parser for several  escape sequences causes the first character following the
  sequence to be ignored (bsc#1220585). Patch backported from
  version 335n.

Package yast2-http-server was updated:

- bsc#1218943  - followup of previous fix - fixed internal issue which caused
    Server modules not to be displayed at all.
  - 4.4.3

Package yast2-network was updated:

- Guard secret attributes against leaking to the log (bsc#1221194)- 4.4.60

Package yast2-packager was updated:

- Reimplemented the hardcoded product mapping to support also the  migration from SLE_HPC to SLES SP6+ (with the HPC module)
  (bsc#1220567)
- 4.4.35

- Do not fail when the installation URL contains a space
  (bsc#1201816)
- 4.4.34

Package yast2-registration was updated:

- Set the new product mapping when upgrading SLE_HPC to SLES SP6+  (with the HPC module), use the old product mapping when upgrading
  from SLE_HPC-SP3 to SLE_HPC-SP4 (bsc#1220567)
- 4.4.24

Package yast2-users was updated:

- Add a missing require in the auto client (bsc#1219422).- 4.4.16

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)

- Do not try to refresh repo metadata as non-root user
  (bsc#1222086)
  Instead show refresh stats and hint how to update them.
- man: Explain how to protect orphaned packages by collecting
  them in a plaindir repo.
- packages: Add --autoinstalled and --userinstalled options to
  list them.
- Don't print 'reboot required' message if download-only or
  dry-run (fixes #529)
  Instead point out that a reboot would be required if the option
  was not used.
- Resepect zypper.conf option `showAlias` search commands
  (bsc#1221963)
  Repository::asUserString (or Repository::label) respects the
  zypper.conf option, while name/alias return the property.
- version 1.14.71

- dup: New option --remove-orphaned to remove all orphaned
  packages in dup (bsc#1221525)
- version 1.14.70

- info,summary: Support VendorSupportOption flag
  VendorSupportSuperseded (jsc#OBS-301, jsc#PED-8014)
- BuildRequires:  libzypp-devel &amp;gt;= 17.32.0.
  API cleanup and changes for VendorSupportSuperseded.
- Show active dry-run/download-only at the commit propmpt.
- patch: Add --skip-not-applicable-patches option (closes #514)
- Fix printing detailed solver problem description.
  The problem description() is one rule out possibly many in
  completeProblemInfo() the solver has chosen to represent the
  problem. So either description or completeProblemInfo should be
  printed, but not both.
- Fix bash-completion to work with right adjusted numbers in the
  1st column too (closes #505)
- Set libzypp shutdown request signal on Ctrl+C (fixes #522)
- lr REPO: In the detailed view show all baseurls not just the
  first one (bsc#1218171)
- version 1.14.69

</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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <Branch Type="Product Name" Name="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
        <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
      </Branch>
    </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="audit-3.0.6-150400.4.16.1">
      <FullProductName ProductID="audit-3.0.6-150400.4.16.1">audit-3.0.6-150400.4.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="audit-audispd-plugins-3.0.6-150400.4.16.1">
      <FullProductName ProductID="audit-audispd-plugins-3.0.6-150400.4.16.1">audit-audispd-plugins-3.0.6-150400.4.16.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="bind-utils-9.16.48-150400.5.40.1">
      <FullProductName ProductID="bind-utils-9.16.48-150400.5.40.1">bind-utils-9.16.48-150400.5.40.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ca-certificates-2+git20240416.98ae794-150300.4.3.3">
      <FullProductName ProductID="ca-certificates-2+git20240416.98ae794-150300.4.3.3">ca-certificates-2+git20240416.98ae794-150300.4.3.3</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="catatonit-0.2.0-150300.10.8.1">
      <FullProductName ProductID="catatonit-0.2.0-150300.10.8.1">catatonit-0.2.0-150300.10.8.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-netconfig-gce-1.14-150000.25.23.1">
      <FullProductName ProductID="cloud-netconfig-gce-1.14-150000.25.23.1">cloud-netconfig-gce-1.14-150000.25.23.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-10.1.7-150000.6.108.1">
      <FullProductName ProductID="cloud-regionsrv-client-10.1.7-150000.6.108.1">cloud-regionsrv-client-10.1.7-150000.6.108.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cloud-regionsrv-client-plugin-gce-1.0.0-150000.6.108.1">
      <FullProductName ProductID="cloud-regionsrv-client-plugin-gce-1.0.0-150000.6.108.1">cloud-regionsrv-client-plugin-gce-1.0.0-150000.6.108.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="cluster-md-kmp-default-5.14.21-150400.24.125.1">
      <FullProductName ProductID="cluster-md-kmp-default-5.14.21-150400.24.125.1">cluster-md-kmp-default-5.14.21-150400.24.125.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="coreutils-8.32-150400.9.6.1">
      <FullProductName ProductID="coreutils-8.32-150400.9.6.1">coreutils-8.32-150400.9.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="crmsh-4.4.2+20240424.6adcc38-150400.3.34.6">
      <FullProductName ProductID="crmsh-4.4.2+20240424.6adcc38-150400.3.34.6">crmsh-4.4.2+20240424.6adcc38-150400.3.34.6</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="crmsh-scripts-4.4.2+20240424.6adcc38-150400.3.34.6">
      <FullProductName ProductID="crmsh-scripts-4.4.2+20240424.6adcc38-150400.3.34.6">crmsh-scripts-4.4.2+20240424.6adcc38-150400.3.34.6</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="curl-8.0.1-150400.5.44.1">
      <FullProductName ProductID="curl-8.0.1-150400.5.44.1">curl-8.0.1-150400.5.44.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="dhcp-4.3.6.P1-150000.6.19.1">
      <FullProductName ProductID="dhcp-4.3.6.P1-150000.6.19.1">dhcp-4.3.6.P1-150000.6.19.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="dhcp-client-4.3.6.P1-150000.6.19.1">
      <FullProductName ProductID="dhcp-client-4.3.6.P1-150000.6.19.1">dhcp-client-4.3.6.P1-150000.6.19.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="dlm-kmp-default-5.14.21-150400.24.125.1">
      <FullProductName ProductID="dlm-kmp-default-5.14.21-150400.24.125.1">dlm-kmp-default-5.14.21-150400.24.125.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.357.g905645c2-150400.3.34.2">
      <FullProductName ProductID="dracut-055+suse.357.g905645c2-150400.3.34.2">dracut-055+suse.357.g905645c2-150400.3.34.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="e2fsprogs-1.46.4-150400.3.6.2">
      <FullProductName ProductID="e2fsprogs-1.46.4-150400.3.6.2">e2fsprogs-1.46.4-150400.3.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="expat-2.4.4-150400.3.17.1">
      <FullProductName ProductID="expat-2.4.4-150400.3.17.1">expat-2.4.4-150400.3.17.1</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-150400.24.125.1">
      <FullProductName ProductID="gfs2-kmp-default-5.14.21-150400.24.125.1">gfs2-kmp-default-5.14.21-150400.24.125.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="gnutls-3.7.3-150400.4.44.1">
      <FullProductName ProductID="gnutls-3.7.3-150400.4.44.1">gnutls-3.7.3-150400.4.44.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="graphviz-2.48.0-150400.3.3.1">
      <FullProductName ProductID="graphviz-2.48.0-150400.3.3.1">graphviz-2.48.0-150400.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="graphviz-gd-2.48.0-150400.3.3.1">
      <FullProductName ProductID="graphviz-gd-2.48.0-150400.3.3.1">graphviz-gd-2.48.0-150400.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="graphviz-plugins-core-2.48.0-150400.3.3.1">
      <FullProductName ProductID="graphviz-plugins-core-2.48.0-150400.3.3.1">graphviz-plugins-core-2.48.0-150400.3.3.1</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="hawk2-2.6.4+git.1708604510.dc8c081f-150000.3.45.1">
      <FullProductName ProductID="hawk2-2.6.4+git.1708604510.dc8c081f-150000.3.45.1">hawk2-2.6.4+git.1708604510.dc8c081f-150000.3.45.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ipset-7.15-150400.12.6.4">
      <FullProductName ProductID="ipset-7.15-150400.12.6.4">ipset-7.15-150400.12.6.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="iputils-20211215-150400.3.14.1">
      <FullProductName ProductID="iputils-20211215-150400.3.14.1">iputils-20211215-150400.3.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="kernel-default-5.14.21-150400.24.125.1">
      <FullProductName ProductID="kernel-default-5.14.21-150400.24.125.1">kernel-default-5.14.21-150400.24.125.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="krb5-1.19.2-150400.3.12.1">
      <FullProductName ProductID="krb5-1.19.2-150400.3.12.1">krb5-1.19.2-150400.3.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="krb5-client-1.19.2-150400.3.12.1">
      <FullProductName ProductID="krb5-client-1.19.2-150400.3.12.1">krb5-client-1.19.2-150400.3.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ldirectord-4.10.0+git40.0f4de473-150400.3.28.2">
      <FullProductName ProductID="ldirectord-4.10.0+git40.0f4de473-150400.3.28.2">ldirectord-4.10.0+git40.0f4de473-150400.3.28.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="less-590-150400.3.9.1">
      <FullProductName ProductID="less-590-150400.3.9.1">less-590-150400.3.9.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="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="libaudit1-3.0.6-150400.4.16.1">
      <FullProductName ProductID="libaudit1-3.0.6-150400.4.16.1">libaudit1-3.0.6-150400.4.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libauparse0-3.0.6-150400.4.16.1">
      <FullProductName ProductID="libauparse0-3.0.6-150400.4.16.1">libauparse0-3.0.6-150400.4.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libavahi-client3-0.8-150400.7.16.1">
      <FullProductName ProductID="libavahi-client3-0.8-150400.7.16.1">libavahi-client3-0.8-150400.7.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libavahi-common3-0.8-150400.7.16.1">
      <FullProductName ProductID="libavahi-common3-0.8-150400.7.16.1">libavahi-common3-0.8-150400.7.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libblkid1-2.37.2-150400.8.29.1">
      <FullProductName ProductID="libblkid1-2.37.2-150400.8.29.1">libblkid1-2.37.2-150400.8.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcairo2-1.16.0-150400.11.3.1">
      <FullProductName ProductID="libcairo2-1.16.0-150400.11.3.1">libcairo2-1.16.0-150400.11.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcares2-1.19.1-150000.3.26.1">
      <FullProductName ProductID="libcares2-1.19.1-150000.3.26.1">libcares2-1.19.1-150000.3.26.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libcom_err2-1.46.4-150400.3.6.2">
      <FullProductName ProductID="libcom_err2-1.46.4-150400.3.6.2">libcom_err2-1.46.4-150400.3.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="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="libcurl4-8.0.1-150400.5.44.1">
      <FullProductName ProductID="libcurl4-8.0.1-150400.5.44.1">libcurl4-8.0.1-150400.5.44.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libexpat1-2.4.4-150400.3.17.1">
      <FullProductName ProductID="libexpat1-2.4.4-150400.3.17.1">libexpat1-2.4.4-150400.3.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libext2fs2-1.46.4-150400.3.6.2">
      <FullProductName ProductID="libext2fs2-1.46.4-150400.3.6.2">libext2fs2-1.46.4-150400.3.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libfdisk1-2.37.2-150400.8.29.1">
      <FullProductName ProductID="libfdisk1-2.37.2-150400.8.29.1">libfdisk1-2.37.2-150400.8.29.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="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="libgnutls30-3.7.3-150400.4.44.1">
      <FullProductName ProductID="libgnutls30-3.7.3-150400.4.44.1">libgnutls30-3.7.3-150400.4.44.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="libgraphviz6-2.48.0-150400.3.3.1">
      <FullProductName ProductID="libgraphviz6-2.48.0-150400.3.3.1">libgraphviz6-2.48.0-150400.3.3.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="libipset13-7.15-150400.12.6.4">
      <FullProductName ProductID="libipset13-7.15-150400.12.6.4">libipset13-7.15-150400.12.6.4</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="libmaxminddb0-1.4.3-150000.1.8.1">
      <FullProductName ProductID="libmaxminddb0-1.4.3-150000.1.8.1">libmaxminddb0-1.4.3-150000.1.8.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libmetalink3-0.1.3-150000.3.2.1">
      <FullProductName ProductID="libmetalink3-0.1.3-150000.3.2.1">libmetalink3-0.1.3-150000.3.2.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libmount1-2.37.2-150400.8.29.1">
      <FullProductName ProductID="libmount1-2.37.2-150400.8.29.1">libmount1-2.37.2-150400.8.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libncurses6-6.1-150000.5.24.1">
      <FullProductName ProductID="libncurses6-6.1-150000.5.24.1">libncurses6-6.1-150000.5.24.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libnftables1-0.9.8-150400.6.3.1">
      <FullProductName ProductID="libnftables1-0.9.8-150400.6.3.1">libnftables1-0.9.8-150400.6.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libnghttp2-14-1.40.0-150200.17.1">
      <FullProductName ProductID="libnghttp2-14-1.40.0-150200.17.1">libnghttp2-14-1.40.0-150200.17.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-150400.7.69.1">
      <FullProductName ProductID="libopenssl1_1-1.1.1l-150400.7.69.1">libopenssl1_1-1.1.1l-150400.7.69.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libpacemaker3-2.1.2+20211124.ada5c3b36-150400.4.20.1">
      <FullProductName ProductID="libpacemaker3-2.1.2+20211124.ada5c3b36-150400.4.20.1">libpacemaker3-2.1.2+20211124.ada5c3b36-150400.4.20.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="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.4+20211112.a2691b9-150400.4.6.2">
      <FullProductName ProductID="libqb100-2.0.4+20211112.a2691b9-150400.4.6.2">libqb100-2.0.4+20211112.a2691b9-150400.4.6.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsemanage1-3.1-150400.3.4.2">
      <FullProductName ProductID="libsemanage1-3.1-150400.3.4.2">libsemanage1-3.1-150400.3.4.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libsmartcols1-2.37.2-150400.8.29.1">
      <FullProductName ProductID="libsmartcols1-2.37.2-150400.8.29.1">libsmartcols1-2.37.2-150400.8.29.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="libssh-config-0.9.8-150400.3.6.1">
      <FullProductName ProductID="libssh-config-0.9.8-150400.3.6.1">libssh-config-0.9.8-150400.3.6.1</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="libssh4-0.9.8-150400.3.6.1">
      <FullProductName ProductID="libssh4-0.9.8-150400.3.6.1">libssh4-0.9.8-150400.3.6.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-150400.3.36.4">
      <FullProductName ProductID="libsuseconnect-1.11.0-150400.3.36.4">libsuseconnect-1.11.0-150400.3.36.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.2-150400.8.29.1">
      <FullProductName ProductID="libuuid1-2.37.2-150400.8.29.1">libuuid1-2.37.2-150400.8.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libvirt-client-8.0.0-150400.7.11.2">
      <FullProductName ProductID="libvirt-client-8.0.0-150400.7.11.2">libvirt-client-8.0.0-150400.7.11.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libvirt-libs-8.0.0-150400.7.11.2">
      <FullProductName ProductID="libvirt-libs-8.0.0-150400.7.11.2">libvirt-libs-8.0.0-150400.7.11.2</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-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.9.14-150400.5.32.1">
      <FullProductName ProductID="libxml2-2-2.9.14-150400.5.32.1">libxml2-2-2.9.14-150400.5.32.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libxml2-tools-2.9.14-150400.5.32.1">
      <FullProductName ProductID="libxml2-tools-2.9.14-150400.5.32.1">libxml2-tools-2.9.14-150400.5.32.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.3.7-150400.3.9.10">
      <FullProductName ProductID="libyui-ncurses-pkg16-4.3.7-150400.3.9.10">libyui-ncurses-pkg16-4.3.7-150400.3.9.10</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libyui-ncurses16-4.3.7-150400.3.9.9">
      <FullProductName ProductID="libyui-ncurses16-4.3.7-150400.3.9.9">libyui-ncurses16-4.3.7-150400.3.9.9</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libyui-qt16-4.3.7-150400.3.9.9">
      <FullProductName ProductID="libyui-qt16-4.3.7-150400.3.9.9">libyui-qt16-4.3.7-150400.3.9.9</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libyui16-4.3.7-150400.3.9.9">
      <FullProductName ProductID="libyui16-4.3.7-150400.3.9.9">libyui16-4.3.7-150400.3.9.9</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="libzypp-17.34.1-150400.3.71.7">
      <FullProductName ProductID="libzypp-17.34.1-150400.3.71.7">libzypp-17.34.1-150400.3.71.7</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="ncurses-utils-6.1-150000.5.24.1">
      <FullProductName ProductID="ncurses-utils-6.1-150000.5.24.1">ncurses-utils-6.1-150000.5.24.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="netcfg-11.6-150000.3.6.1">
      <FullProductName ProductID="netcfg-11.6-150000.3.6.1">netcfg-11.6-150000.3.6.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-150400.24.125.1">
      <FullProductName ProductID="ocfs2-kmp-default-5.14.21-150400.24.125.1">ocfs2-kmp-default-5.14.21-150400.24.125.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="ocfs2-tools-1.8.7-150400.6.12.2">
      <FullProductName ProductID="ocfs2-tools-1.8.7-150400.6.12.2">ocfs2-tools-1.8.7-150400.6.12.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="opensc-0.22.0-150400.3.9.1">
      <FullProductName ProductID="opensc-0.22.0-150400.3.9.1">opensc-0.22.0-150400.3.9.1</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="openssh-8.4p1-150300.3.37.1">
      <FullProductName ProductID="openssh-8.4p1-150300.3.37.1">openssh-8.4p1-150300.3.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-clients-8.4p1-150300.3.37.1">
      <FullProductName ProductID="openssh-clients-8.4p1-150300.3.37.1">openssh-clients-8.4p1-150300.3.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-common-8.4p1-150300.3.37.1">
      <FullProductName ProductID="openssh-common-8.4p1-150300.3.37.1">openssh-common-8.4p1-150300.3.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssh-server-8.4p1-150300.3.37.1">
      <FullProductName ProductID="openssh-server-8.4p1-150300.3.37.1">openssh-server-8.4p1-150300.3.37.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="openssl-1_1-1.1.1l-150400.7.69.1">
      <FullProductName ProductID="openssl-1_1-1.1.1l-150400.7.69.1">openssl-1_1-1.1.1l-150400.7.69.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pacemaker-2.1.2+20211124.ada5c3b36-150400.4.20.1">
      <FullProductName ProductID="pacemaker-2.1.2+20211124.ada5c3b36-150400.4.20.1">pacemaker-2.1.2+20211124.ada5c3b36-150400.4.20.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pacemaker-cli-2.1.2+20211124.ada5c3b36-150400.4.20.1">
      <FullProductName ProductID="pacemaker-cli-2.1.2+20211124.ada5c3b36-150400.4.20.1">pacemaker-cli-2.1.2+20211124.ada5c3b36-150400.4.20.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pam-config-1.1-150200.3.6.1">
      <FullProductName ProductID="pam-config-1.1-150200.3.6.1">pam-config-1.1-150200.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="pam_pkcs11-0.6.10-150100.3.3.2">
      <FullProductName ProductID="pam_pkcs11-0.6.10-150100.3.3.2">pam_pkcs11-0.6.10-150100.3.3.2</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="perl-5.26.1-150300.17.17.1">
      <FullProductName ProductID="perl-5.26.1-150300.17.17.1">perl-5.26.1-150300.17.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="perl-Bootloader-0.947-150400.3.12.1">
      <FullProductName ProductID="perl-Bootloader-0.947-150400.3.12.1">perl-Bootloader-0.947-150400.3.12.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="perl-base-5.26.1-150300.17.17.1">
      <FullProductName ProductID="perl-base-5.26.1-150300.17.17.1">perl-base-5.26.1-150300.17.17.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="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-Jinja2-2.10.1-150000.3.13.1">
      <FullProductName ProductID="python3-Jinja2-2.10.1-150000.3.13.1">python3-Jinja2-2.10.1-150000.3.13.1</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-bind-9.16.48-150400.5.40.1">
      <FullProductName ProductID="python3-bind-9.16.48-150400.5.40.1">python3-bind-9.16.48-150400.5.40.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-idna-2.6-150000.3.3.1">
      <FullProductName ProductID="python3-idna-2.6-150000.3.3.1">python3-idna-2.6-150000.3.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-nftables-0.9.8-150400.6.3.1">
      <FullProductName ProductID="python3-nftables-0.9.8-150400.6.3.1">python3-nftables-0.9.8-150400.6.3.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-pycryptodome-3.9.0-150200.9.1">
      <FullProductName ProductID="python3-pycryptodome-3.9.0-150200.9.1">python3-pycryptodome-3.9.0-150200.9.1</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-rpm-4.14.3-150400.59.16.1">
      <FullProductName ProductID="python3-rpm-4.14.3-150400.59.16.1">python3-rpm-4.14.3-150400.59.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="python3-salt-3006.0-150400.8.63.2">
      <FullProductName ProductID="python3-salt-3006.0-150400.8.63.2">python3-salt-3006.0-150400.8.63.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.10.0+git40.0f4de473-150400.3.28.2">
      <FullProductName ProductID="resource-agents-4.10.0+git40.0f4de473-150400.3.28.2">resource-agents-4.10.0+git40.0f4de473-150400.3.28.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="rpm-ndb-4.14.3-150400.59.16.1">
      <FullProductName ProductID="rpm-ndb-4.14.3-150400.59.16.1">rpm-ndb-4.14.3-150400.59.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="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-rack-2.0.8-150000.3.21.2">
      <FullProductName ProductID="ruby2.5-rubygem-rack-2.0.8-150000.3.21.2">ruby2.5-rubygem-rack-2.0.8-150000.3.21.2</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="salt-3006.0-150400.8.63.2">
      <FullProductName ProductID="salt-3006.0-150400.8.63.2">salt-3006.0-150400.8.63.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="salt-minion-3006.0-150400.8.63.2">
      <FullProductName ProductID="salt-minion-3006.0-150400.8.63.2">salt-minion-3006.0-150400.8.63.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="salt-standalone-formulas-configuration-3006.0-150400.8.63.2">
      <FullProductName ProductID="salt-standalone-formulas-configuration-3006.0-150400.8.63.2">salt-standalone-formulas-configuration-3006.0-150400.8.63.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="sapconf-5.0.7-150400.16.4.1">
      <FullProductName ProductID="sapconf-5.0.7-150400.16.4.1">sapconf-5.0.7-150400.16.4.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="saptune-3.1.2-150400.15.4.1">
      <FullProductName ProductID="saptune-3.1.2-150400.15.4.1">saptune-3.1.2-150400.15.4.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="sed-4.4-150300.13.3.1">
      <FullProductName ProductID="sed-4.4-150300.13.3.1">sed-4.4-150300.13.3.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="shim-15.8-150300.4.20.2">
      <FullProductName ProductID="shim-15.8-150300.4.20.2">shim-15.8-150300.4.20.2</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="sudo-1.9.9-150400.4.36.1">
      <FullProductName ProductID="sudo-1.9.9-150400.4.36.1">sudo-1.9.9-150400.4.36.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="supportutils-plugin-ha-sap-0.0.5+git.1709295499.1c8e8cd-150000.1.15.1">
      <FullProductName ProductID="supportutils-plugin-ha-sap-0.0.5+git.1709295499.1c8e8cd-150000.1.15.1">supportutils-plugin-ha-sap-0.0.5+git.1709295499.1c8e8cd-150000.1.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="supportutils-plugin-suse-public-cloud-1.0.9-150000.3.20.1">
      <FullProductName ProductID="supportutils-plugin-suse-public-cloud-1.0.9-150000.3.20.1">supportutils-plugin-suse-public-cloud-1.0.9-150000.3.20.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="suseconnect-ng-1.11.0-150400.3.36.4">
      <FullProductName ProductID="suseconnect-ng-1.11.0-150400.3.36.4">suseconnect-ng-1.11.0-150400.3.36.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="suseconnect-ruby-bindings-1.11.0-150400.3.36.4">
      <FullProductName ProductID="suseconnect-ruby-bindings-1.11.0-150400.3.36.4">suseconnect-ruby-bindings-1.11.0-150400.3.36.4</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="system-group-audit-3.0.6-150400.4.16.1">
      <FullProductName ProductID="system-group-audit-3.0.6-150400.4.16.1">system-group-audit-3.0.6-150400.4.16.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-default-settings-0.10-150300.3.7.1">
      <FullProductName ProductID="systemd-default-settings-0.10-150300.3.7.1">systemd-default-settings-0.10-150300.3.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-default-settings-branding-SLE-0.10-150300.3.7.1">
      <FullProductName ProductID="systemd-default-settings-branding-SLE-0.10-150300.3.7.1">systemd-default-settings-branding-SLE-0.10-150300.3.7.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-presets-branding-SLE-15.1-150100.20.14.1">
      <FullProductName ProductID="systemd-presets-branding-SLE-15.1-150100.20.14.1">systemd-presets-branding-SLE-15.1-150100.20.14.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-presets-common-SUSE-15-150100.8.23.1">
      <FullProductName ProductID="systemd-presets-common-SUSE-15-150100.8.23.1">systemd-presets-common-SUSE-15-150100.8.23.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="systemd-rpm-macros-15-150000.7.39.1">
      <FullProductName ProductID="systemd-rpm-macros-15-150000.7.39.1">systemd-rpm-macros-15-150000.7.39.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="terminfo-6.1-150000.5.24.1">
      <FullProductName ProductID="terminfo-6.1-150000.5.24.1">terminfo-6.1-150000.5.24.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="terminfo-base-6.1-150000.5.24.1">
      <FullProductName ProductID="terminfo-base-6.1-150000.5.24.1">terminfo-base-6.1-150000.5.24.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="timezone-2024a-150000.75.28.1">
      <FullProductName ProductID="timezone-2024a-150000.75.28.1">timezone-2024a-150000.75.28.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="util-linux-2.37.2-150400.8.29.1">
      <FullProductName ProductID="util-linux-2.37.2-150400.8.29.1">util-linux-2.37.2-150400.8.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="util-linux-systemd-2.37.2-150400.8.29.1">
      <FullProductName ProductID="util-linux-systemd-2.37.2-150400.8.29.1">util-linux-systemd-2.37.2-150400.8.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="uuidd-2.37.2-150400.8.29.1">
      <FullProductName ProductID="uuidd-2.37.2-150400.8.29.1">uuidd-2.37.2-150400.8.29.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-9.1.0330-150000.5.63.1">
      <FullProductName ProductID="vim-9.1.0330-150000.5.63.1">vim-9.1.0330-150000.5.63.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="vim-data-common-9.1.0330-150000.5.63.1">
      <FullProductName ProductID="vim-data-common-9.1.0330-150000.5.63.1">vim-data-common-9.1.0330-150000.5.63.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-150400.3.30.1">
      <FullProductName ProductID="wicked-0.6.76-150400.3.30.1">wicked-0.6.76-150400.3.30.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="wicked-service-0.6.76-150400.3.30.1">
      <FullProductName ProductID="wicked-service-0.6.76-150400.3.30.1">wicked-service-0.6.76-150400.3.30.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="xen-libs-4.16.6_02-150400.4.55.1">
      <FullProductName ProductID="xen-libs-4.16.6_02-150400.4.55.1">xen-libs-4.16.6_02-150400.4.55.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="xterm-bin-330-150200.11.15.1">
      <FullProductName ProductID="xterm-bin-330-150200.11.15.1">xterm-bin-330-150200.11.15.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-http-server-4.4.3-150400.3.6.1">
      <FullProductName ProductID="yast2-http-server-4.4.3-150400.3.6.1">yast2-http-server-4.4.3-150400.3.6.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-network-4.4.60-150400.3.30.1">
      <FullProductName ProductID="yast2-network-4.4.60-150400.3.30.1">yast2-network-4.4.60-150400.3.30.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-packager-4.4.35-150400.3.11.1">
      <FullProductName ProductID="yast2-packager-4.4.35-150400.3.11.1">yast2-packager-4.4.35-150400.3.11.1</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-pkg-bindings-4.4.7-150400.3.13.10">
      <FullProductName ProductID="yast2-pkg-bindings-4.4.7-150400.3.13.10">yast2-pkg-bindings-4.4.7-150400.3.13.10</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-registration-4.4.24-150400.3.9.2">
      <FullProductName ProductID="yast2-registration-4.4.24-150400.3.9.2">yast2-registration-4.4.24-150400.3.9.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="yast2-users-4.4.16-150400.3.18.2">
      <FullProductName ProductID="yast2-users-4.4.16-150400.3.18.2">yast2-users-4.4.16-150400.3.18.2</FullProductName>
    </Branch>
    <Branch Type="Product Version" Name="zypper-1.14.73-150400.3.50.10">
      <FullProductName ProductID="zypper-1.14.73-150400.3.50.10">zypper-1.14.73-150400.3.50.10</FullProductName>
    </Branch>
    <Relationship ProductReference="SAPHanaSR-0.162.4-150000.4.44.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="audit-3.0.6-150400.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:audit-3.0.6-150400.4.16.1">audit-3.0.6-150400.4.16.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="audit-audispd-plugins-3.0.6-150400.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:audit-audispd-plugins-3.0.6-150400.4.16.1">audit-audispd-plugins-3.0.6-150400.4.16.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="bind-utils-9.16.48-150400.5.40.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:bind-utils-9.16.48-150400.5.40.1">bind-utils-9.16.48-150400.5.40.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ca-certificates-2+git20240416.98ae794-150300.4.3.3" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:ca-certificates-2+git20240416.98ae794-150300.4.3.3">ca-certificates-2+git20240416.98ae794-150300.4.3.3 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="catatonit-0.2.0-150300.10.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:catatonit-0.2.0-150300.10.8.1">catatonit-0.2.0-150300.10.8.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-netconfig-gce-1.14-150000.25.23.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:cloud-netconfig-gce-1.14-150000.25.23.1">cloud-netconfig-gce-1.14-150000.25.23.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-10.1.7-150000.6.108.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:cloud-regionsrv-client-10.1.7-150000.6.108.1">cloud-regionsrv-client-10.1.7-150000.6.108.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cloud-regionsrv-client-plugin-gce-1.0.0-150000.6.108.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:cloud-regionsrv-client-plugin-gce-1.0.0-150000.6.108.1">cloud-regionsrv-client-plugin-gce-1.0.0-150000.6.108.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="cluster-md-kmp-default-5.14.21-150400.24.125.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:cluster-md-kmp-default-5.14.21-150400.24.125.1">cluster-md-kmp-default-5.14.21-150400.24.125.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="coreutils-8.32-150400.9.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:coreutils-8.32-150400.9.6.1">coreutils-8.32-150400.9.6.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="crmsh-4.4.2+20240424.6adcc38-150400.3.34.6" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:crmsh-4.4.2+20240424.6adcc38-150400.3.34.6">crmsh-4.4.2+20240424.6adcc38-150400.3.34.6 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="crmsh-scripts-4.4.2+20240424.6adcc38-150400.3.34.6" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:crmsh-scripts-4.4.2+20240424.6adcc38-150400.3.34.6">crmsh-scripts-4.4.2+20240424.6adcc38-150400.3.34.6 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="curl-8.0.1-150400.5.44.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:curl-8.0.1-150400.5.44.1">curl-8.0.1-150400.5.44.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="dhcp-4.3.6.P1-150000.6.19.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:dhcp-4.3.6.P1-150000.6.19.1">dhcp-4.3.6.P1-150000.6.19.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="dhcp-client-4.3.6.P1-150000.6.19.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:dhcp-client-4.3.6.P1-150000.6.19.1">dhcp-client-4.3.6.P1-150000.6.19.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="dlm-kmp-default-5.14.21-150400.24.125.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:dlm-kmp-default-5.14.21-150400.24.125.1">dlm-kmp-default-5.14.21-150400.24.125.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="dracut-055+suse.357.g905645c2-150400.3.34.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:dracut-055+suse.357.g905645c2-150400.3.34.2">dracut-055+suse.357.g905645c2-150400.3.34.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="e2fsprogs-1.46.4-150400.3.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:e2fsprogs-1.46.4-150400.3.6.2">e2fsprogs-1.46.4-150400.3.6.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="expat-2.4.4-150400.3.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:expat-2.4.4-150400.3.17.1">expat-2.4.4-150400.3.17.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="gfs2-kmp-default-5.14.21-150400.24.125.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:gfs2-kmp-default-5.14.21-150400.24.125.1">gfs2-kmp-default-5.14.21-150400.24.125.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="gnutls-3.7.3-150400.4.44.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:gnutls-3.7.3-150400.4.44.1">gnutls-3.7.3-150400.4.44.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="graphviz-2.48.0-150400.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:graphviz-2.48.0-150400.3.3.1">graphviz-2.48.0-150400.3.3.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="graphviz-gd-2.48.0-150400.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:graphviz-gd-2.48.0-150400.3.3.1">graphviz-gd-2.48.0-150400.3.3.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="graphviz-plugins-core-2.48.0-150400.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:graphviz-plugins-core-2.48.0-150400.3.3.1">graphviz-plugins-core-2.48.0-150400.3.3.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="hawk2-2.6.4+git.1708604510.dc8c081f-150000.3.45.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:hawk2-2.6.4+git.1708604510.dc8c081f-150000.3.45.1">hawk2-2.6.4+git.1708604510.dc8c081f-150000.3.45.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ipset-7.15-150400.12.6.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:ipset-7.15-150400.12.6.4">ipset-7.15-150400.12.6.4 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="iputils-20211215-150400.3.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:iputils-20211215-150400.3.14.1">iputils-20211215-150400.3.14.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="kernel-default-5.14.21-150400.24.125.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:kernel-default-5.14.21-150400.24.125.1">kernel-default-5.14.21-150400.24.125.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="krb5-1.19.2-150400.3.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:krb5-1.19.2-150400.3.12.1">krb5-1.19.2-150400.3.12.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="krb5-client-1.19.2-150400.3.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:krb5-client-1.19.2-150400.3.12.1">krb5-client-1.19.2-150400.3.12.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ldirectord-4.10.0+git40.0f4de473-150400.3.28.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:ldirectord-4.10.0+git40.0f4de473-150400.3.28.2">ldirectord-4.10.0+git40.0f4de473-150400.3.28.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="less-590-150400.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:less-590-150400.3.9.1">less-590-150400.3.9.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libaudit1-3.0.6-150400.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libaudit1-3.0.6-150400.4.16.1">libaudit1-3.0.6-150400.4.16.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libauparse0-3.0.6-150400.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libauparse0-3.0.6-150400.4.16.1">libauparse0-3.0.6-150400.4.16.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libavahi-client3-0.8-150400.7.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libavahi-client3-0.8-150400.7.16.1">libavahi-client3-0.8-150400.7.16.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libavahi-common3-0.8-150400.7.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libavahi-common3-0.8-150400.7.16.1">libavahi-common3-0.8-150400.7.16.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libblkid1-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libblkid1-2.37.2-150400.8.29.1">libblkid1-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcairo2-1.16.0-150400.11.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libcairo2-1.16.0-150400.11.3.1">libcairo2-1.16.0-150400.11.3.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcares2-1.19.1-150000.3.26.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libcares2-1.19.1-150000.3.26.1">libcares2-1.19.1-150000.3.26.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcom_err2-1.46.4-150400.3.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libcom_err2-1.46.4-150400.3.6.2">libcom_err2-1.46.4-150400.3.6.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libcurl4-8.0.1-150400.5.44.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libcurl4-8.0.1-150400.5.44.1">libcurl4-8.0.1-150400.5.44.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libexpat1-2.4.4-150400.3.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libexpat1-2.4.4-150400.3.17.1">libexpat1-2.4.4-150400.3.17.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libext2fs2-1.46.4-150400.3.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libext2fs2-1.46.4-150400.3.6.2">libext2fs2-1.46.4-150400.3.6.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libfdisk1-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libfdisk1-2.37.2-150400.8.29.1">libfdisk1-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgnutls30-3.7.3-150400.4.44.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libgnutls30-3.7.3-150400.4.44.1">libgnutls30-3.7.3-150400.4.44.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libgraphviz6-2.48.0-150400.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libgraphviz6-2.48.0-150400.3.3.1">libgraphviz6-2.48.0-150400.3.3.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libipset13-7.15-150400.12.6.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libipset13-7.15-150400.12.6.4">libipset13-7.15-150400.12.6.4 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libmaxminddb0-1.4.3-150000.1.8.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libmaxminddb0-1.4.3-150000.1.8.1">libmaxminddb0-1.4.3-150000.1.8.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libmetalink3-0.1.3-150000.3.2.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libmetalink3-0.1.3-150000.3.2.1">libmetalink3-0.1.3-150000.3.2.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libmount1-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libmount1-2.37.2-150400.8.29.1">libmount1-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libncurses6-6.1-150000.5.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libncurses6-6.1-150000.5.24.1">libncurses6-6.1-150000.5.24.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libnftables1-0.9.8-150400.6.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libnftables1-0.9.8-150400.6.3.1">libnftables1-0.9.8-150400.6.3.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libnghttp2-14-1.40.0-150200.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libnghttp2-14-1.40.0-150200.17.1">libnghttp2-14-1.40.0-150200.17.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libopenssl1_1-1.1.1l-150400.7.69.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libopenssl1_1-1.1.1l-150400.7.69.1">libopenssl1_1-1.1.1l-150400.7.69.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libpacemaker3-2.1.2+20211124.ada5c3b36-150400.4.20.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libpacemaker3-2.1.2+20211124.ada5c3b36-150400.4.20.1">libpacemaker3-2.1.2+20211124.ada5c3b36-150400.4.20.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libqb100-2.0.4+20211112.a2691b9-150400.4.6.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libqb100-2.0.4+20211112.a2691b9-150400.4.6.2">libqb100-2.0.4+20211112.a2691b9-150400.4.6.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsemanage1-3.1-150400.3.4.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libsemanage1-3.1-150400.3.4.2">libsemanage1-3.1-150400.3.4.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsmartcols1-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libsmartcols1-2.37.2-150400.8.29.1">libsmartcols1-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libssh-config-0.9.8-150400.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libssh-config-0.9.8-150400.3.6.1">libssh-config-0.9.8-150400.3.6.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libssh4-0.9.8-150400.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libssh4-0.9.8-150400.3.6.1">libssh4-0.9.8-150400.3.6.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libsuseconnect-1.11.0-150400.3.36.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libsuseconnect-1.11.0-150400.3.36.4">libsuseconnect-1.11.0-150400.3.36.4 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libuuid1-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libuuid1-2.37.2-150400.8.29.1">libuuid1-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libvirt-client-8.0.0-150400.7.11.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libvirt-client-8.0.0-150400.7.11.2">libvirt-client-8.0.0-150400.7.11.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libvirt-libs-8.0.0-150400.7.11.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libvirt-libs-8.0.0-150400.7.11.2">libvirt-libs-8.0.0-150400.7.11.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxml2-2-2.9.14-150400.5.32.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libxml2-2-2.9.14-150400.5.32.1">libxml2-2-2.9.14-150400.5.32.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libxml2-tools-2.9.14-150400.5.32.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libxml2-tools-2.9.14-150400.5.32.1">libxml2-tools-2.9.14-150400.5.32.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libyui-ncurses-pkg16-4.3.7-150400.3.9.10" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libyui-ncurses-pkg16-4.3.7-150400.3.9.10">libyui-ncurses-pkg16-4.3.7-150400.3.9.10 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libyui-ncurses16-4.3.7-150400.3.9.9" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libyui-ncurses16-4.3.7-150400.3.9.9">libyui-ncurses16-4.3.7-150400.3.9.9 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libyui-qt16-4.3.7-150400.3.9.9" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libyui-qt16-4.3.7-150400.3.9.9">libyui-qt16-4.3.7-150400.3.9.9 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libyui16-4.3.7-150400.3.9.9" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libyui16-4.3.7-150400.3.9.9">libyui16-4.3.7-150400.3.9.9 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="libzypp-17.34.1-150400.3.71.7" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:libzypp-17.34.1-150400.3.71.7">libzypp-17.34.1-150400.3.71.7 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ncurses-utils-6.1-150000.5.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:ncurses-utils-6.1-150000.5.24.1">ncurses-utils-6.1-150000.5.24.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="netcfg-11.6-150000.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:netcfg-11.6-150000.3.6.1">netcfg-11.6-150000.3.6.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ocfs2-kmp-default-5.14.21-150400.24.125.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:ocfs2-kmp-default-5.14.21-150400.24.125.1">ocfs2-kmp-default-5.14.21-150400.24.125.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ocfs2-tools-1.8.7-150400.6.12.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:ocfs2-tools-1.8.7-150400.6.12.2">ocfs2-tools-1.8.7-150400.6.12.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="opensc-0.22.0-150400.3.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:opensc-0.22.0-150400.3.9.1">opensc-0.22.0-150400.3.9.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-8.4p1-150300.3.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:openssh-8.4p1-150300.3.37.1">openssh-8.4p1-150300.3.37.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-clients-8.4p1-150300.3.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:openssh-clients-8.4p1-150300.3.37.1">openssh-clients-8.4p1-150300.3.37.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-common-8.4p1-150300.3.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:openssh-common-8.4p1-150300.3.37.1">openssh-common-8.4p1-150300.3.37.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssh-server-8.4p1-150300.3.37.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:openssh-server-8.4p1-150300.3.37.1">openssh-server-8.4p1-150300.3.37.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="openssl-1_1-1.1.1l-150400.7.69.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:openssl-1_1-1.1.1l-150400.7.69.1">openssl-1_1-1.1.1l-150400.7.69.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pacemaker-2.1.2+20211124.ada5c3b36-150400.4.20.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:pacemaker-2.1.2+20211124.ada5c3b36-150400.4.20.1">pacemaker-2.1.2+20211124.ada5c3b36-150400.4.20.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pacemaker-cli-2.1.2+20211124.ada5c3b36-150400.4.20.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:pacemaker-cli-2.1.2+20211124.ada5c3b36-150400.4.20.1">pacemaker-cli-2.1.2+20211124.ada5c3b36-150400.4.20.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pam-config-1.1-150200.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:pam-config-1.1-150200.3.6.1">pam-config-1.1-150200.3.6.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="pam_pkcs11-0.6.10-150100.3.3.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:pam_pkcs11-0.6.10-150100.3.3.2">pam_pkcs11-0.6.10-150100.3.3.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="perl-5.26.1-150300.17.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:perl-5.26.1-150300.17.17.1">perl-5.26.1-150300.17.17.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="perl-Bootloader-0.947-150400.3.12.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:perl-Bootloader-0.947-150400.3.12.1">perl-Bootloader-0.947-150400.3.12.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="perl-base-5.26.1-150300.17.17.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:perl-base-5.26.1-150300.17.17.1">perl-base-5.26.1-150300.17.17.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-Jinja2-2.10.1-150000.3.13.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:python3-Jinja2-2.10.1-150000.3.13.1">python3-Jinja2-2.10.1-150000.3.13.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-bind-9.16.48-150400.5.40.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:python3-bind-9.16.48-150400.5.40.1">python3-bind-9.16.48-150400.5.40.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-idna-2.6-150000.3.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:python3-idna-2.6-150000.3.3.1">python3-idna-2.6-150000.3.3.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-nftables-0.9.8-150400.6.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:python3-nftables-0.9.8-150400.6.3.1">python3-nftables-0.9.8-150400.6.3.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-pycryptodome-3.9.0-150200.9.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:python3-pycryptodome-3.9.0-150200.9.1">python3-pycryptodome-3.9.0-150200.9.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-rpm-4.14.3-150400.59.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:python3-rpm-4.14.3-150400.59.16.1">python3-rpm-4.14.3-150400.59.16.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="python3-salt-3006.0-150400.8.63.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:python3-salt-3006.0-150400.8.63.2">python3-salt-3006.0-150400.8.63.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="resource-agents-4.10.0+git40.0f4de473-150400.3.28.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:resource-agents-4.10.0+git40.0f4de473-150400.3.28.2">resource-agents-4.10.0+git40.0f4de473-150400.3.28.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="rpm-ndb-4.14.3-150400.59.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:rpm-ndb-4.14.3-150400.59.16.1">rpm-ndb-4.14.3-150400.59.16.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="ruby2.5-rubygem-rack-2.0.8-150000.3.21.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:ruby2.5-rubygem-rack-2.0.8-150000.3.21.2">ruby2.5-rubygem-rack-2.0.8-150000.3.21.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-3006.0-150400.8.63.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:salt-3006.0-150400.8.63.2">salt-3006.0-150400.8.63.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-minion-3006.0-150400.8.63.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:salt-minion-3006.0-150400.8.63.2">salt-minion-3006.0-150400.8.63.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="salt-standalone-formulas-configuration-3006.0-150400.8.63.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:salt-standalone-formulas-configuration-3006.0-150400.8.63.2">salt-standalone-formulas-configuration-3006.0-150400.8.63.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="sapconf-5.0.7-150400.16.4.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:sapconf-5.0.7-150400.16.4.1">sapconf-5.0.7-150400.16.4.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="saptune-3.1.2-150400.15.4.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:saptune-3.1.2-150400.15.4.1">saptune-3.1.2-150400.15.4.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="sed-4.4-150300.13.3.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:sed-4.4-150300.13.3.1">sed-4.4-150300.13.3.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="shim-15.8-150300.4.20.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:shim-15.8-150300.4.20.2">shim-15.8-150300.4.20.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="sudo-1.9.9-150400.4.36.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:sudo-1.9.9-150400.4.36.1">sudo-1.9.9-150400.4.36.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="supportutils-plugin-ha-sap-0.0.5+git.1709295499.1c8e8cd-150000.1.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:supportutils-plugin-ha-sap-0.0.5+git.1709295499.1c8e8cd-150000.1.15.1">supportutils-plugin-ha-sap-0.0.5+git.1709295499.1c8e8cd-150000.1.15.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="supportutils-plugin-suse-public-cloud-1.0.9-150000.3.20.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:supportutils-plugin-suse-public-cloud-1.0.9-150000.3.20.1">supportutils-plugin-suse-public-cloud-1.0.9-150000.3.20.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ng-1.11.0-150400.3.36.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:suseconnect-ng-1.11.0-150400.3.36.4">suseconnect-ng-1.11.0-150400.3.36.4 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="suseconnect-ruby-bindings-1.11.0-150400.3.36.4" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:suseconnect-ruby-bindings-1.11.0-150400.3.36.4">suseconnect-ruby-bindings-1.11.0-150400.3.36.4 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="system-group-audit-3.0.6-150400.4.16.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:system-group-audit-3.0.6-150400.4.16.1">system-group-audit-3.0.6-150400.4.16.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-default-settings-0.10-150300.3.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:systemd-default-settings-0.10-150300.3.7.1">systemd-default-settings-0.10-150300.3.7.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-default-settings-branding-SLE-0.10-150300.3.7.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:systemd-default-settings-branding-SLE-0.10-150300.3.7.1">systemd-default-settings-branding-SLE-0.10-150300.3.7.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-presets-branding-SLE-15.1-150100.20.14.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:systemd-presets-branding-SLE-15.1-150100.20.14.1">systemd-presets-branding-SLE-15.1-150100.20.14.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-presets-common-SUSE-15-150100.8.23.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:systemd-presets-common-SUSE-15-150100.8.23.1">systemd-presets-common-SUSE-15-150100.8.23.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="systemd-rpm-macros-15-150000.7.39.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:systemd-rpm-macros-15-150000.7.39.1">systemd-rpm-macros-15-150000.7.39.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="terminfo-6.1-150000.5.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:terminfo-6.1-150000.5.24.1">terminfo-6.1-150000.5.24.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="terminfo-base-6.1-150000.5.24.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:terminfo-base-6.1-150000.5.24.1">terminfo-base-6.1-150000.5.24.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="timezone-2024a-150000.75.28.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:timezone-2024a-150000.75.28.1">timezone-2024a-150000.75.28.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:util-linux-2.37.2-150400.8.29.1">util-linux-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="util-linux-systemd-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:util-linux-systemd-2.37.2-150400.8.29.1">util-linux-systemd-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="uuidd-2.37.2-150400.8.29.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:uuidd-2.37.2-150400.8.29.1">uuidd-2.37.2-150400.8.29.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-9.1.0330-150000.5.63.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:vim-9.1.0330-150000.5.63.1">vim-9.1.0330-150000.5.63.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="vim-data-common-9.1.0330-150000.5.63.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:vim-data-common-9.1.0330-150000.5.63.1">vim-data-common-9.1.0330-150000.5.63.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wicked-0.6.76-150400.3.30.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:wicked-0.6.76-150400.3.30.1">wicked-0.6.76-150400.3.30.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="wicked-service-0.6.76-150400.3.30.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:wicked-service-0.6.76-150400.3.30.1">wicked-service-0.6.76-150400.3.30.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="xen-libs-4.16.6_02-150400.4.55.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:xen-libs-4.16.6_02-150400.4.55.1">xen-libs-4.16.6_02-150400.4.55.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="xterm-bin-330-150200.11.15.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:xterm-bin-330-150200.11.15.1">xterm-bin-330-150200.11.15.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-http-server-4.4.3-150400.3.6.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:yast2-http-server-4.4.3-150400.3.6.1">yast2-http-server-4.4.3-150400.3.6.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-network-4.4.60-150400.3.30.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:yast2-network-4.4.60-150400.3.30.1">yast2-network-4.4.60-150400.3.30.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-packager-4.4.35-150400.3.11.1" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:yast2-packager-4.4.35-150400.3.11.1">yast2-packager-4.4.35-150400.3.11.1 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-pkg-bindings-4.4.7-150400.3.13.10" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:yast2-pkg-bindings-4.4.7-150400.3.13.10">yast2-pkg-bindings-4.4.7-150400.3.13.10 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-registration-4.4.24-150400.3.9.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:yast2-registration-4.4.24-150400.3.9.2">yast2-registration-4.4.24-150400.3.9.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="yast2-users-4.4.16-150400.3.18.2" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:yast2-users-4.4.16-150400.3.18.2">yast2-users-4.4.16-150400.3.18.2 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64</FullProductName>
    </Relationship>
    <Relationship ProductReference="zypper-1.14.73-150400.3.50.10" RelationType="Default Component Of" RelatesToProductReference="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64">
      <FullProductName ProductID="Public Cloud Image google/sles-sap-15-sp4-hardened-byos-v20240808-x86-64:zypper-1.14.73-150400.3.50.10">zypper-1.14.73-150400.3.50.10 as a component of Public Cloud Image google/sles-sap-15-sp4-hardened-byos-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">An issue was discovered in Perl 5.22 through 5.26. Matching a crafted locale dependent regular expression can cause a heap-based buffer over-read and potentially information disclosure.</Note>
    </Notes>
    <CVE>CVE-2018-6798</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:P/I:N/A:N</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Heap-based buffer overflow in the pack function in Perl before 5.26.2 allows context-dependent attackers to execute arbitrary code via a large item count.</Note>
    </Notes>
    <CVE>CVE-2018-6913</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>7.5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:P/I:P/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i2c: Fix a potential use after free

Free the adap structure only after we are done using it.
This patch just moves the put_device() down a bit to avoid the
use after free.

[wsa: added comment to the code, added Fixes tag]</Note>
    </Notes>
    <CVE>CVE-2019-25162</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 cairo 1.16.0. There is an infinite loop in the function _arc_error_normalized in the file cairo-arc.c, related to _arc_max_angle_for_tolerance_normalized.</Note>
    </Notes>
    <CVE>CVE-2019-6462</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</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 the Linux kernel, the following vulnerability has been resolved:

drm/nouveau: avoid a use-after-free when BO init fails

nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code
back to the caller. On failures, ttm_bo_init() invokes the provided
destructor which should de-initialize and free the memory.

Thus, when nouveau_bo_init() returns an error the gem object has already
been released and the memory freed by nouveau_bo_del_ttm().</Note>
    </Notes>
    <CVE>CVE-2020-36788</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Integer Overflow or Wraparound vulnerability in openEuler kernel on Linux (filesystem modules) allows Forced Integer Overflow.This issue affects openEuler kernel: from 4.19.90 before 4.19.90-2401.3, from 5.10.0-60.18.0 before 5.10.0-183.0.0.

</Note>
    </Notes>
    <CVE>CVE-2021-33631</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="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">A vulnerability was found in the Linux kernel's block_invalidatepage in fs/buffer.c in the filesystem. A missing sanity check may allow a local attacker with user privilege to cause a denial of service (DOS) problem.</Note>
    </Notes>
    <CVE>CVE-2021-4148</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">dp_link_settings_write in drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c in the Linux kernel through 5.14.14 allows a heap-based buffer overflow by an attacker who can write a string to the AMD GPU display drivers debug filesystem. There are no checks on size within parse_write_buffer_into_params when it uses the size of copy_from_user to copy a userspace buffer into a 40-byte heap buffer.</Note>
    </Notes>
    <CVE>CVE-2021-42327</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>4.6</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:P/I:P/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was discovered in the Linux kernel 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:

fs/mount_setattr: always cleanup mount_kattr

Make sure that finish_mount_kattr() is called after mount_kattr was
succesfully built in both the success and failure case to prevent
leaking any references we took when we built it.  We returned early if
path lookup failed thereby risking to leak an additional reference we
took when building mount_kattr when an idmapped mount was requested.</Note>
    </Notes>
    <CVE>CVE-2021-46923</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: st21nfca: Fix memory leak in device probe and remove

'phy-&gt;pending_skb' is alloced when device probe, but forgot to free
in the error handling path and remove path, this cause memory leak
as follows:

unreferenced object 0xffff88800bc06800 (size 512):
  comm "8", pid 11775, jiffies 4295159829 (age 9.032s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;00000000d66c09ce&gt;] __kmalloc_node_track_caller+0x1ed/0x450
    [&lt;00000000c93382b3&gt;] kmalloc_reserve+0x37/0xd0
    [&lt;000000005fea522c&gt;] __alloc_skb+0x124/0x380
    [&lt;0000000019f29f9a&gt;] st21nfca_hci_i2c_probe+0x170/0x8f2

Fix it by freeing 'pending_skb' in error and remove.</Note>
    </Notes>
    <CVE>CVE-2021-46924</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 kernel panic caused by race of smc_sock

A crash occurs when smc_cdc_tx_handler() tries to access smc_sock
but smc_release() has already freed it.

[ 4570.695099] BUG: unable to handle page fault for address: 000000002eae9e88
[ 4570.696048] #PF: supervisor write access in kernel mode
[ 4570.696728] #PF: error_code(0x0002) - not-present page
[ 4570.697401] PGD 0 P4D 0
[ 4570.697716] Oops: 0002 [#1] PREEMPT SMP NOPTI
[ 4570.698228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111
[ 4570.699013] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/0
[ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30
&lt;...&gt;
[ 4570.711446] Call Trace:
[ 4570.711746]  &lt;IRQ&gt;
[ 4570.711992]  smc_cdc_tx_handler+0x41/0xc0
[ 4570.712470]  smc_wr_tx_tasklet_fn+0x213/0x560
[ 4570.712981]  ? smc_cdc_tx_dismisser+0x10/0x10
[ 4570.713489]  tasklet_action_common.isra.17+0x66/0x140
[ 4570.714083]  __do_softirq+0x123/0x2f4
[ 4570.714521]  irq_exit_rcu+0xc4/0xf0
[ 4570.714934]  common_interrupt+0xba/0xe0

Though smc_cdc_tx_handler() checked the existence of smc connection,
smc_release() may have already dismissed and released the smc socket
before smc_cdc_tx_handler() further visits it.

smc_cdc_tx_handler()           |smc_release()
if (!conn)                     |
                               |
                               |smc_cdc_tx_dismiss_slots()
                               |      smc_cdc_tx_dismisser()
                               |
                               |sock_put(&amp;smc-&gt;sk) &lt;- last sock_put,
                               |                      smc_sock freed
bh_lock_sock(&amp;smc-&gt;sk) (panic) |

To make sure we won't receive any CDC messages after we free the
smc_sock, add a refcount on the smc_connection for inflight CDC
message(posted to the QP but haven't received related CQE), and
don't release the smc_connection until all the inflight CDC messages
haven been done, for both success or failed ones.

Using refcount on CDC messages brings another problem: when the link
is going to be destroyed, smcr_link_clear() will reset the QP, which
then remove all the pending CQEs related to the QP in the CQ. To make
sure all the CQEs will always come back so the refcount on the
smc_connection can always reach 0, smc_ib_modify_qp_reset() was replaced
by smc_ib_modify_qp_error().
And remove the timeout in smc_wr_tx_wait_no_pending_sends() since we
need to wait for all pending WQEs done, or we may encounter use-after-
free when handling CQEs.

For IB device removal routine, we need to wait for all the QPs on that
device been destroyed before we can destroy CQs on the device, or
the refcount on smc_connection won't reach 0 and smc_sock cannot be
released.</Note>
    </Notes>
    <CVE>CVE-2021-46925</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: harden detection of controller

The existing code currently sets a pointer to an ACPI handle before
checking that it's actually a SoundWire controller. This can lead to
issues where the graph walk continues and eventually fails, but the
pointer was set already.

This patch changes the logic so that the information provided to
the caller is set when a controller is found.</Note>
    </Notes>
    <CVE>CVE-2021-46926</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:

nitro_enclaves: Use get_user_pages_unlocked() call to handle mmap assert

After commit 5b78ed24e8ec ("mm/pagemap: add mmap_assert_locked()
annotations to find_vma*()"), the call to get_user_pages() will trigger
the mmap assert.

static inline void mmap_assert_locked(struct mm_struct *mm)
{
	lockdep_assert_held(&amp;mm-&gt;mmap_lock);
	VM_BUG_ON_MM(!rwsem_is_locked(&amp;mm-&gt;mmap_lock), mm);
}

[   62.521410] kernel BUG at include/linux/mmap_lock.h:156!
...........................................................
[   62.538938] RIP: 0010:find_vma+0x32/0x80
...........................................................
[   62.605889] Call Trace:
[   62.608502]  &lt;TASK&gt;
[   62.610956]  ? lock_timer_base+0x61/0x80
[   62.614106]  find_extend_vma+0x19/0x80
[   62.617195]  __get_user_pages+0x9b/0x6a0
[   62.620356]  __gup_longterm_locked+0x42d/0x450
[   62.623721]  ? finish_wait+0x41/0x80
[   62.626748]  ? __kmalloc+0x178/0x2f0
[   62.629768]  ne_set_user_memory_region_ioctl.isra.0+0x225/0x6a0 [nitro_enclaves]
[   62.635776]  ne_enclave_ioctl+0x1cf/0x6d7 [nitro_enclaves]
[   62.639541]  __x64_sys_ioctl+0x82/0xb0
[   62.642620]  do_syscall_64+0x3b/0x90
[   62.645642]  entry_SYSCALL_64_after_hwframe+0x44/0xae

Use get_user_pages_unlocked() when setting the enclave memory regions.
That's a similar pattern as mmap_read_lock() used together with
get_user_pages().</Note>
    </Notes>
    <CVE>CVE-2021-46927</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: mtu3: fix list_head check warning

This is caused by uninitialization of list_head.

BUG: KASAN: use-after-free in __list_del_entry_valid+0x34/0xe4

Call trace:
dump_backtrace+0x0/0x298
show_stack+0x24/0x34
dump_stack+0x130/0x1a8
print_address_description+0x88/0x56c
__kasan_report+0x1b8/0x2a0
kasan_report+0x14/0x20
__asan_load8+0x9c/0xa0
__list_del_entry_valid+0x34/0xe4
mtu3_req_complete+0x4c/0x300 [mtu3]
mtu3_gadget_stop+0x168/0x448 [mtu3]
usb_gadget_unregister_driver+0x204/0x3a0
unregister_gadget_item+0x44/0xa4</Note>
    </Notes>
    <CVE>CVE-2021-46930</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Wrap the tx reporter dump callback to extract the sq

Function mlx5e_tx_reporter_dump_sq() casts its void * argument to struct
mlx5e_txqsq *, but in TX-timeout-recovery flow the argument is actually
of type struct mlx5e_tx_timeout_ctx *.

 mlx5_core 0000:08:00.1 enp8s0f1: TX timeout detected
 mlx5_core 0000:08:00.1 enp8s0f1: TX timeout on queue: 1, SQ: 0x11ec, CQ: 0x146d, SQ Cons: 0x0 SQ Prod: 0x1, usecs since last trans: 21565000
 BUG: stack guard page was hit at 0000000093f1a2de (stack is 00000000b66ea0dc..000000004d932dae)
 kernel stack overflow (page fault): 0000 [#1] SMP NOPTI
 CPU: 5 PID: 95 Comm: kworker/u20:1 Tainted: G W OE 5.13.0_mlnx #1
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
 Workqueue: mlx5e mlx5e_tx_timeout_work [mlx5_core]
 RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180
 [mlx5_core]
 Call Trace:
 mlx5e_tx_reporter_dump+0x43/0x1c0 [mlx5_core]
 devlink_health_do_dump.part.91+0x71/0xd0
 devlink_health_report+0x157/0x1b0
 mlx5e_reporter_tx_timeout+0xb9/0xf0 [mlx5_core]
 ? mlx5e_tx_reporter_err_cqe_recover+0x1d0/0x1d0
 [mlx5_core]
 ? mlx5e_health_queue_dump+0xd0/0xd0 [mlx5_core]
 ? update_load_avg+0x19b/0x550
 ? set_next_entity+0x72/0x80
 ? pick_next_task_fair+0x227/0x340
 ? finish_task_switch+0xa2/0x280
   mlx5e_tx_timeout_work+0x83/0xb0 [mlx5_core]
   process_one_work+0x1de/0x3a0
   worker_thread+0x2d/0x3c0
 ? process_one_work+0x3a0/0x3a0
   kthread+0x115/0x130
 ? kthread_park+0x90/0x90
   ret_from_fork+0x1f/0x30
 --[ end trace 51ccabea504edaff ]---
 RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180
 PKRU: 55555554
 Kernel panic - not syncing: Fatal exception
 Kernel Offset: disabled
 end Kernel panic - not syncing: Fatal exception

To fix this bug add a wrapper for mlx5e_tx_reporter_dump_sq() which
extracts the sq from struct mlx5e_tx_timeout_ctx and set it as the
TX-timeout-recovery flow dump callback.</Note>
    </Notes>
    <CVE>CVE-2021-46931</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: appletouch - initialize work before device registration

Syzbot has reported warning in __flush_work(). This warning is caused by
work-&gt;func == NULL, which means missing work initialization.

This may happen, since input_dev-&gt;close() calls
cancel_work_sync(&amp;dev-&gt;work), but dev-&gt;work initalization happens _after_
input_register_device() call.

So this patch moves dev-&gt;work initialization before registering input
device</Note>
    </Notes>
    <CVE>CVE-2021-46932</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear.

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

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

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

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

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

Wrong user data may cause warning in i2c_transfer(), ex: zero msgs.
Userspace should not be able to trigger warnings, so this patch adds
validation checks for user data in compact ioctl to prevent reported
warnings</Note>
    </Notes>
    <CVE>CVE-2021-46934</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: fix use-after-free in tw_timer_handler

A real world panic issue was found as follow in Linux 5.4.

    BUG: unable to handle page fault for address: ffffde49a863de28
    PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0
    RIP: 0010:tw_timer_handler+0x20/0x40
    Call Trace:
     &lt;IRQ&gt;
     call_timer_fn+0x2b/0x120
     run_timer_softirq+0x1ef/0x450
     __do_softirq+0x10d/0x2b8
     irq_exit+0xc7/0xd0
     smp_apic_timer_interrupt+0x68/0x120
     apic_timer_interrupt+0xf/0x20

This issue was also reported since 2017 in the thread [1],
unfortunately, the issue was still can be reproduced after fixing
DCCP.

The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a net
namespace is destroyed since tcp_sk_ops is registered befrore
ipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_ops
in the list of pernet_list. There will be a use-after-free on
net-&gt;mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net
if there are some inflight time-wait timers.

This bug is not introduced by commit f2bf415cfed7 ("mib: add net to
NET_ADD_STATS_BH") since the net_statistics is a global variable
instead of dynamic allocation and freeing. Actually, commit
61a7e26028b9 ("mib: put net statistics on struct net") introduces
the bug since it put net statistics on struct net and free it when
net namespace is destroyed.

Moving init_ipv4_mibs() to the front of tcp_init() to fix this bug
and replace pr_crit() with panic() since continuing is meaningless
when init_ipv4_mibs() fails.

[1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1</Note>
    </Notes>
    <CVE>CVE-2021-46936</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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

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

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

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

When eint virtual eint number is greater than gpio number,
it maybe produce 'desc[eint_n]' size globle-out-of-bounds issue.</Note>
    </Notes>
    <CVE>CVE-2021-47083</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tee: optee: Fix incorrect page free bug

Pointer to the allocated pages (struct page *page) has already
progressed towards the end of allocation. It is incorrect to perform
__free_pages(page, order) using this pointer as we would free any
arbitrary pages. Fix this by stop modifying the page pointer.</Note>
    </Notes>
    <CVE>CVE-2021-47087</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 locking in ieee80211_start_ap error path

We need to hold the local-&gt;mtx to release the channel context,
as even encoded by the lockdep_assert_held() there. Fix it.</Note>
    </Notes>
    <CVE>CVE-2021-47091</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: intel_pmc_core: fix memleak on registration failure

In case device registration fails during module initialisation, the
platform device structure needs to be freed using platform_device_put()
to properly free all resources (e.g. the device name).</Note>
    </Notes>
    <CVE>CVE-2021-47093</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

KVM: x86/mmu: Don't advance iterator after restart due to yielding

After dropping mmu_lock in the TDP MMU, restart the iterator during
tdp_iter_next() and do not advance the iterator.  Advancing the iterator
results in skipping the top-level SPTE and all its children, which is
fatal if any of the skipped SPTEs were not visited before yielding.

When zapping all SPTEs, i.e. when min_level == root_level, restarting the
iter and then invoking tdp_iter_next() is always fatal if the current gfn
has as a valid SPTE, as advancing the iterator results in try_step_side()
skipping the current gfn, which wasn't visited before yielding.

Sprinkle WARNs on iter-&gt;yielded being true in various helpers that are
often used in conjunction with yielding, and tag the helper with
__must_check to reduce the probabily of improper usage.

Failing to zap a top-level SPTE manifests in one of two ways.  If a valid
SPTE is skipped by both kvm_tdp_mmu_zap_all() and kvm_tdp_mmu_put_root(),
the shadow page will be leaked and KVM will WARN accordingly.

  WARNING: CPU: 1 PID: 3509 at arch/x86/kvm/mmu/tdp_mmu.c:46 [kvm]
  RIP: 0010:kvm_mmu_uninit_tdp_mmu+0x3e/0x50 [kvm]
  Call Trace:
   &lt;TASK&gt;
   kvm_arch_destroy_vm+0x130/0x1b0 [kvm]
   kvm_destroy_vm+0x162/0x2a0 [kvm]
   kvm_vcpu_release+0x34/0x60 [kvm]
   __fput+0x82/0x240
   task_work_run+0x5c/0x90
   do_exit+0x364/0xa10
   ? futex_unqueue+0x38/0x60
   do_group_exit+0x33/0xa0
   get_signal+0x155/0x850
   arch_do_signal_or_restart+0xed/0x750
   exit_to_user_mode_prepare+0xc5/0x120
   syscall_exit_to_user_mode+0x1d/0x40
   do_syscall_64+0x48/0xc0
   entry_SYSCALL_64_after_hwframe+0x44/0xae

If kvm_tdp_mmu_zap_all() skips a gfn/SPTE but that SPTE is then zapped by
kvm_tdp_mmu_put_root(), KVM triggers a use-after-free in the form of
marking a struct page as dirty/accessed after it has been put back on the
free list.  This directly triggers a WARN due to encountering a page with
page_count() == 0, but it can also lead to data corruption and additional
errors in the kernel.

  WARNING: CPU: 7 PID: 1995658 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:171
  RIP: 0010:kvm_is_zone_device_pfn.part.0+0x9e/0xd0 [kvm]
  Call Trace:
   &lt;TASK&gt;
   kvm_set_pfn_dirty+0x120/0x1d0 [kvm]
   __handle_changed_spte+0x92e/0xca0 [kvm]
   __handle_changed_spte+0x63c/0xca0 [kvm]
   __handle_changed_spte+0x63c/0xca0 [kvm]
   __handle_changed_spte+0x63c/0xca0 [kvm]
   zap_gfn_range+0x549/0x620 [kvm]
   kvm_tdp_mmu_put_root+0x1b6/0x270 [kvm]
   mmu_free_root_page+0x219/0x2c0 [kvm]
   kvm_mmu_free_roots+0x1b4/0x4e0 [kvm]
   kvm_mmu_unload+0x1c/0xa0 [kvm]
   kvm_arch_destroy_vm+0x1f2/0x5c0 [kvm]
   kvm_put_kvm+0x3b1/0x8b0 [kvm]
   kvm_vcpu_release+0x4e/0x70 [kvm]
   __fput+0x1f7/0x8c0
   task_work_run+0xf8/0x1a0
   do_exit+0x97b/0x2230
   do_group_exit+0xda/0x2a0
   get_signal+0x3be/0x1e50
   arch_do_signal_or_restart+0x244/0x17f0
   exit_to_user_mode_prepare+0xcb/0x120
   syscall_exit_to_user_mode+0x1d/0x40
   do_syscall_64+0x4d/0x90
   entry_SYSCALL_64_after_hwframe+0x44/0xae

Note, the underlying bug existed even before commit 1af4a96025b3 ("KVM:
x86/mmu: Yield in TDU MMU iter even if no SPTES changed") moved calls to
tdp_mmu_iter_cond_resched() to the beginning of loops, as KVM could still
incorrectly advance past a top-level entry when yielding on a lower-level
entry.  But with respect to leaking shadow pages, the bug was introduced
by yielding before processing the current gfn.

Alternatively, tdp_mmu_iter_cond_resched() could simply fall through, or
callers could jump to their "retry" label.  The downside of that approach
is that tdp_mmu_iter_cond_resched() _must_ be called before anything else
in the loop, and there's no easy way to enfornce that requirement.

Ideally, KVM would handling the cond_resched() fully within the iterator
macro (the code is actually quite clean) and avoid this entire class of
bugs, but that is extremely difficult do wh
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47094</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:

ipmi: ssif: initialize ssif_info-&gt;client early

During probe ssif_info-&gt;client is dereferenced in error path. However,
it is set when some of the error checking has already been done. This
causes following kernel crash if an error path is taken:

[   30.645593][  T674] ipmi_ssif 0-000e: ipmi_ssif: Not probing, Interface already present
[   30.657616][  T674] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088
...
[   30.657723][  T674] pc : __dev_printk+0x28/0xa0
[   30.657732][  T674] lr : _dev_err+0x7c/0xa0
...
[   30.657772][  T674] Call trace:
[   30.657775][  T674]  __dev_printk+0x28/0xa0
[   30.657778][  T674]  _dev_err+0x7c/0xa0
[   30.657781][  T674]  ssif_probe+0x548/0x900 [ipmi_ssif 62ce4b08badc1458fd896206d9ef69a3c31f3d3e]
[   30.657791][  T674]  i2c_device_probe+0x37c/0x3c0
...

Initialize ssif_info-&gt;client before any error path can be taken. Clear
i2c_client data in the error path to prevent the dangling pointer from
leaking.</Note>
    </Notes>
    <CVE>CVE-2021-47095</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: rawmidi - fix the uninitalized user_pversion

The user_pversion was uninitialized for the user space file structure
in the open function, because the file private structure use
kmalloc for the allocation.

The kernel ALSA sequencer code clears the file structure, so no additional
fixes are required.

BugLink: https://github.com/alsa-project/alsa-lib/issues/178</Note>
    </Notes>
    <CVE>CVE-2021-47096</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: elantech - fix stack out of bound access in elantech_change_report_id()

The array param[] in elantech_change_report_id() must be at least 3
bytes, because elantech_read_reg_params() is calling ps2_command() with
PSMOUSE_CMD_GETINFO, that is going to access 3 bytes from param[], but
it's defined in the stack as an array of 2 bytes, therefore we have a
potential stack out-of-bounds access here, also confirmed by KASAN:

[    6.512374] BUG: KASAN: stack-out-of-bounds in __ps2_command+0x372/0x7e0
[    6.512397] Read of size 1 at addr ffff8881024d77c2 by task kworker/2:1/118

[    6.512416] CPU: 2 PID: 118 Comm: kworker/2:1 Not tainted 5.13.0-22-generic #22+arighi20211110
[    6.512428] Hardware name: LENOVO 20T8000QGE/20T8000QGE, BIOS R1AET32W (1.08 ) 08/14/2020
[    6.512436] Workqueue: events_long serio_handle_event
[    6.512453] Call Trace:
[    6.512462]  show_stack+0x52/0x58
[    6.512474]  dump_stack+0xa1/0xd3
[    6.512487]  print_address_description.constprop.0+0x1d/0x140
[    6.512502]  ? __ps2_command+0x372/0x7e0
[    6.512516]  __kasan_report.cold+0x7d/0x112
[    6.512527]  ? _raw_write_lock_irq+0x20/0xd0
[    6.512539]  ? __ps2_command+0x372/0x7e0
[    6.512552]  kasan_report+0x3c/0x50
[    6.512564]  __asan_load1+0x6a/0x70
[    6.512575]  __ps2_command+0x372/0x7e0
[    6.512589]  ? ps2_drain+0x240/0x240
[    6.512601]  ? dev_printk_emit+0xa2/0xd3
[    6.512612]  ? dev_vprintk_emit+0xc5/0xc5
[    6.512621]  ? __kasan_check_write+0x14/0x20
[    6.512634]  ? mutex_lock+0x8f/0xe0
[    6.512643]  ? __mutex_lock_slowpath+0x20/0x20
[    6.512655]  ps2_command+0x52/0x90
[    6.512670]  elantech_ps2_command+0x4f/0xc0 [psmouse]
[    6.512734]  elantech_change_report_id+0x1e6/0x256 [psmouse]
[    6.512799]  ? elantech_report_trackpoint.constprop.0.cold+0xd/0xd [psmouse]
[    6.512863]  ? ps2_command+0x7f/0x90
[    6.512877]  elantech_query_info.cold+0x6bd/0x9ed [psmouse]
[    6.512943]  ? elantech_setup_ps2+0x460/0x460 [psmouse]
[    6.513005]  ? psmouse_reset+0x69/0xb0 [psmouse]
[    6.513064]  ? psmouse_attr_set_helper+0x2a0/0x2a0 [psmouse]
[    6.513122]  ? phys_pmd_init+0x30e/0x521
[    6.513137]  elantech_init+0x8a/0x200 [psmouse]
[    6.513200]  ? elantech_init_ps2+0xf0/0xf0 [psmouse]
[    6.513249]  ? elantech_query_info+0x440/0x440 [psmouse]
[    6.513296]  ? synaptics_send_cmd+0x60/0x60 [psmouse]
[    6.513342]  ? elantech_query_info+0x440/0x440 [psmouse]
[    6.513388]  ? psmouse_try_protocol+0x11e/0x170 [psmouse]
[    6.513432]  psmouse_extensions+0x65d/0x6e0 [psmouse]
[    6.513476]  ? psmouse_try_protocol+0x170/0x170 [psmouse]
[    6.513519]  ? mutex_unlock+0x22/0x40
[    6.513526]  ? ps2_command+0x7f/0x90
[    6.513536]  ? psmouse_probe+0xa3/0xf0 [psmouse]
[    6.513580]  psmouse_switch_protocol+0x27d/0x2e0 [psmouse]
[    6.513624]  psmouse_connect+0x272/0x530 [psmouse]
[    6.513669]  serio_driver_probe+0x55/0x70
[    6.513679]  really_probe+0x190/0x720
[    6.513689]  driver_probe_device+0x160/0x1f0
[    6.513697]  device_driver_attach+0x119/0x130
[    6.513705]  ? device_driver_attach+0x130/0x130
[    6.513713]  __driver_attach+0xe7/0x1a0
[    6.513720]  ? device_driver_attach+0x130/0x130
[    6.513728]  bus_for_each_dev+0xfb/0x150
[    6.513738]  ? subsys_dev_iter_exit+0x10/0x10
[    6.513748]  ? _raw_write_unlock_bh+0x30/0x30
[    6.513757]  driver_attach+0x2d/0x40
[    6.513764]  serio_handle_event+0x199/0x3d0
[    6.513775]  process_one_work+0x471/0x740
[    6.513785]  worker_thread+0x2d2/0x790
[    6.513794]  ? process_one_work+0x740/0x740
[    6.513802]  kthread+0x1b4/0x1e0
[    6.513809]  ? set_kthread_struct+0x80/0x80
[    6.513816]  ret_from_fork+0x22/0x30

[    6.513832] The buggy address belongs to the page:
[    6.513838] page:00000000bc35e189 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1024d7
[    6.513847] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
[    6.513860] raw: 0
---truncated---</Note>
    </Notes>
    <CVE>CVE-2021-47097</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:

hwmon: (lm90) Prevent integer overflow/underflow in hysteresis calculations

Commit b50aa49638c7 ("hwmon: (lm90) Prevent integer underflows of
temperature calculations") addressed a number of underflow situations
when writing temperature limits. However, it missed one situation, seen
when an attempt is made to set the hysteresis value to MAX_LONG and the
critical temperature limit is negative.

Use clamp_val() when setting the hysteresis temperature to ensure that
the provided value can never overflow or underflow.</Note>
    </Notes>
    <CVE>CVE-2021-47098</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

veth: ensure skb entering GRO are not cloned.

After commit d3256efd8e8b ("veth: allow enabling NAPI even without XDP"),
if GRO is enabled on a veth device and TSO is disabled on the peer
device, TCP skbs will go through the NAPI callback. If there is no XDP
program attached, the veth code does not perform any share check, and
shared/cloned skbs could enter the GRO engine.

Ignat reported a BUG triggered later-on due to the above condition:

[   53.970529][    C1] kernel BUG at net/core/skbuff.c:3574!
[   53.981755][    C1] invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
[   53.982634][    C1] CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc5+ #25
[   53.982634][    C1] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
[   53.982634][    C1] RIP: 0010:skb_shift+0x13ef/0x23b0
[   53.982634][    C1] Code: ea 03 0f b6 04 02 48 89 fa 83 e2 07 38 d0
7f 08 84 c0 0f 85 41 0c 00 00 41 80 7f 02 00 4d 8d b5 d0 00 00 00 0f
85 74 f5 ff ff &lt;0f&gt; 0b 4d 8d 77 20 be 04 00 00 00 4c 89 44 24 78 4c 89
f7 4c 89 8c
[   53.982634][    C1] RSP: 0018:ffff8881008f7008 EFLAGS: 00010246
[   53.982634][    C1] RAX: 0000000000000000 RBX: ffff8881180b4c80 RCX: 0000000000000000
[   53.982634][    C1] RDX: 0000000000000002 RSI: ffff8881180b4d3c RDI: ffff88810bc9cac2
[   53.982634][    C1] RBP: ffff8881008f70b8 R08: ffff8881180b4cf4 R09: ffff8881180b4cf0
[   53.982634][    C1] R10: ffffed1022999e5c R11: 0000000000000002 R12: 0000000000000590
[   53.982634][    C1] R13: ffff88810f940c80 R14: ffff88810f940d50 R15: ffff88810bc9cac0
[   53.982634][    C1] FS:  0000000000000000(0000) GS:ffff888235880000(0000) knlGS:0000000000000000
[   53.982634][    C1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   53.982634][    C1] CR2: 00007ff5f9b86680 CR3: 0000000108ce8004 CR4: 0000000000170ee0
[   53.982634][    C1] Call Trace:
[   53.982634][    C1]  &lt;TASK&gt;
[   53.982634][    C1]  tcp_sacktag_walk+0xaba/0x18e0
[   53.982634][    C1]  tcp_sacktag_write_queue+0xe7b/0x3460
[   53.982634][    C1]  tcp_ack+0x2666/0x54b0
[   53.982634][    C1]  tcp_rcv_established+0x4d9/0x20f0
[   53.982634][    C1]  tcp_v4_do_rcv+0x551/0x810
[   53.982634][    C1]  tcp_v4_rcv+0x22ed/0x2ed0
[   53.982634][    C1]  ip_protocol_deliver_rcu+0x96/0xaf0
[   53.982634][    C1]  ip_local_deliver_finish+0x1e0/0x2f0
[   53.982634][    C1]  ip_sublist_rcv_finish+0x211/0x440
[   53.982634][    C1]  ip_list_rcv_finish.constprop.0+0x424/0x660
[   53.982634][    C1]  ip_list_rcv+0x2c8/0x410
[   53.982634][    C1]  __netif_receive_skb_list_core+0x65c/0x910
[   53.982634][    C1]  netif_receive_skb_list_internal+0x5f9/0xcb0
[   53.982634][    C1]  napi_complete_done+0x188/0x6e0
[   53.982634][    C1]  gro_cell_poll+0x10c/0x1d0
[   53.982634][    C1]  __napi_poll+0xa1/0x530
[   53.982634][    C1]  net_rx_action+0x567/0x1270
[   53.982634][    C1]  __do_softirq+0x28a/0x9ba
[   53.982634][    C1]  run_ksoftirqd+0x32/0x60
[   53.982634][    C1]  smpboot_thread_fn+0x559/0x8c0
[   53.982634][    C1]  kthread+0x3b9/0x490
[   53.982634][    C1]  ret_from_fork+0x22/0x30
[   53.982634][    C1]  &lt;/TASK&gt;

Address the issue by skipping the GRO stage for shared or cloned skbs.
To reduce the chance of OoO, try to unclone the skbs before giving up.

v1 -&gt; v2:
 - use avoid skb_copy and fallback to netif_receive_skb  - Eric</Note>
    </Notes>
    <CVE>CVE-2021-47099</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ipmi: Fix UAF when uninstall ipmi_si and ipmi_msghandler module

Hi,

When testing install and uninstall of ipmi_si.ko and ipmi_msghandler.ko,
the system crashed.

The log as follows:
[  141.087026] BUG: unable to handle kernel paging request at ffffffffc09b3a5a
[  141.087241] PGD 8fe4c0d067 P4D 8fe4c0d067 PUD 8fe4c0f067 PMD 103ad89067 PTE 0
[  141.087464] Oops: 0010 [#1] SMP NOPTI
[  141.087580] CPU: 67 PID: 668 Comm: kworker/67:1 Kdump: loaded Not tainted 4.18.0.x86_64 #47
[  141.088009] Workqueue: events 0xffffffffc09b3a40
[  141.088009] RIP: 0010:0xffffffffc09b3a5a
[  141.088009] Code: Bad RIP value.
[  141.088009] RSP: 0018:ffffb9094e2c3e88 EFLAGS: 00010246
[  141.088009] RAX: 0000000000000000 RBX: ffff9abfdb1f04a0 RCX: 0000000000000000
[  141.088009] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
[  141.088009] RBP: 0000000000000000 R08: ffff9abfffee3cb8 R09: 00000000000002e1
[  141.088009] R10: ffffb9094cb73d90 R11: 00000000000f4240 R12: ffff9abfffee8700
[  141.088009] R13: 0000000000000000 R14: ffff9abfdb1f04a0 R15: ffff9abfdb1f04a8
[  141.088009] FS:  0000000000000000(0000) GS:ffff9abfffec0000(0000) knlGS:0000000000000000
[  141.088009] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  141.088009] CR2: ffffffffc09b3a30 CR3: 0000008fe4c0a001 CR4: 00000000007606e0
[  141.088009] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  141.088009] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  141.088009] PKRU: 55555554
[  141.088009] Call Trace:
[  141.088009]  ? process_one_work+0x195/0x390
[  141.088009]  ? worker_thread+0x30/0x390
[  141.088009]  ? process_one_work+0x390/0x390
[  141.088009]  ? kthread+0x10d/0x130
[  141.088009]  ? kthread_flush_work_fn+0x10/0x10
[  141.088009]  ? ret_from_fork+0x35/0x40] BUG: unable to handle kernel paging request at ffffffffc0b28a5a
[  200.223240] PGD 97fe00d067 P4D 97fe00d067 PUD 97fe00f067 PMD a580cbf067 PTE 0
[  200.223464] Oops: 0010 [#1] SMP NOPTI
[  200.223579] CPU: 63 PID: 664 Comm: kworker/63:1 Kdump: loaded Not tainted 4.18.0.x86_64 #46
[  200.224008] Workqueue: events 0xffffffffc0b28a40
[  200.224008] RIP: 0010:0xffffffffc0b28a5a
[  200.224008] Code: Bad RIP value.
[  200.224008] RSP: 0018:ffffbf3c8e2a3e88 EFLAGS: 00010246
[  200.224008] RAX: 0000000000000000 RBX: ffffa0799ad6bca0 RCX: 0000000000000000
[  200.224008] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
[  200.224008] RBP: 0000000000000000 R08: ffff9fe43fde3cb8 R09: 00000000000000d5
[  200.224008] R10: ffffbf3c8cb53d90 R11: 00000000000f4240 R12: ffff9fe43fde8700
[  200.224008] R13: 0000000000000000 R14: ffffa0799ad6bca0 R15: ffffa0799ad6bca8
[  200.224008] FS:  0000000000000000(0000) GS:ffff9fe43fdc0000(0000) knlGS:0000000000000000
[  200.224008] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  200.224008] CR2: ffffffffc0b28a30 CR3: 00000097fe00a002 CR4: 00000000007606e0
[  200.224008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  200.224008] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  200.224008] PKRU: 55555554
[  200.224008] Call Trace:
[  200.224008]  ? process_one_work+0x195/0x390
[  200.224008]  ? worker_thread+0x30/0x390
[  200.224008]  ? process_one_work+0x390/0x390
[  200.224008]  ? kthread+0x10d/0x130
[  200.224008]  ? kthread_flush_work_fn+0x10/0x10
[  200.224008]  ? ret_from_fork+0x35/0x40
[  200.224008] kernel fault(0x1) notification starting on CPU 63
[  200.224008] kernel fault(0x1) notification finished on CPU 63
[  200.224008] CR2: ffffffffc0b28a5a
[  200.224008] ---[ end trace c82a412d93f57412 ]---

The reason is as follows:
T1: rmmod ipmi_si.
    -&gt;ipmi_unregister_smi()
        -&gt; ipmi_bmc_unregister()
            -&gt; __ipmi_bmc_unregister()
                -&gt; kref_put(&amp;bmc-&gt;usecount, cleanup_bmc_device);
                    -&gt; schedule_work(&amp;bmc-&gt;remove_work);

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

asix: fix uninit-value in asix_mdio_read()

asix_read_cmd() may read less than sizeof(smsr) bytes and in this case
smsr will be uninitialized.

Fail log:
BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]
BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497
BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497
 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]
 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497
 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497</Note>
    </Notes>
    <CVE>CVE-2021-47101</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: marvell: prestera: fix incorrect structure access

In line:
	upper = info-&gt;upper_dev;
We access upper_dev field, which is related only for particular events
(e.g. event == NETDEV_CHANGEUPPER). So, this line cause invalid memory
access for another events,
when ptr is not netdev_notifier_changeupper_info.

The KASAN logs are as follows:

[   30.123165] BUG: KASAN: stack-out-of-bounds in prestera_netdev_port_event.constprop.0+0x68/0x538 [prestera]
[   30.133336] Read of size 8 at addr ffff80000cf772b0 by task udevd/778
[   30.139866]
[   30.141398] CPU: 0 PID: 778 Comm: udevd Not tainted 5.16.0-rc3 #6
[   30.147588] Hardware name: DNI AmazonGo1 A7040 board (DT)
[   30.153056] Call trace:
[   30.155547]  dump_backtrace+0x0/0x2c0
[   30.159320]  show_stack+0x18/0x30
[   30.162729]  dump_stack_lvl+0x68/0x84
[   30.166491]  print_address_description.constprop.0+0x74/0x2b8
[   30.172346]  kasan_report+0x1e8/0x250
[   30.176102]  __asan_load8+0x98/0xe0
[   30.179682]  prestera_netdev_port_event.constprop.0+0x68/0x538 [prestera]
[   30.186847]  prestera_netdev_event_handler+0x1b4/0x1c0 [prestera]
[   30.193313]  raw_notifier_call_chain+0x74/0xa0
[   30.197860]  call_netdevice_notifiers_info+0x68/0xc0
[   30.202924]  register_netdevice+0x3cc/0x760
[   30.207190]  register_netdev+0x24/0x50
[   30.211015]  prestera_device_register+0x8a0/0xba0 [prestera]</Note>
    </Notes>
    <CVE>CVE-2021-47102</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

IB/qib: Fix memory leak in qib_user_sdma_queue_pkts()

The wrong goto label was used for the error case and missed cleanup of the
pkt allocation.

Addresses-Coverity-ID: 1493352 ("Resource leak")</Note>
    </Notes>
    <CVE>CVE-2021-47104</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: xsk: return xsk buffers back to pool when cleaning the ring

Currently we only NULL the xdp_buff pointer in the internal SW ring but
we never give it back to the xsk buffer pool. This means that buffers
can be leaked out of the buff pool and never be used again.

Add missing xsk_buff_free() call to the routine that is supposed to
clean the entries that are left in the ring so that these buffers in the
umem can be used by other sockets.

Also, only go through the space that is actually left to be cleaned
instead of a whole ring.</Note>
    </Notes>
    <CVE>CVE-2021-47105</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 READDIR buffer overflow

If a client sends a READDIR count argument that is too small (say,
zero), then the buffer size calculation in the new init_dirlist
helper functions results in an underflow, allowing the XDR stream
functions to write beyond the actual buffer.

This calculation has always been suspect. NFSD has never sanity-
checked the READDIR count argument, but the old entry encoders
managed the problem correctly.

With the commits below, entry encoding changed, exposing the
underflow to the pointer arithmetic in xdr_reserve_space().

Modern NFS clients attempt to retrieve as much data as possible
for each READDIR request. Also, we have no unit tests that
exercise the behavior of READDIR at the lower bound of @count
values. Thus this case was missed during testing.</Note>
    </Notes>
    <CVE>CVE-2021-47107</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: hdmi: Perform NULL pointer check for mtk_hdmi_conf

In commit 41ca9caaae0b
("drm/mediatek: hdmi: Add check for CEA modes only") a check
for CEA modes was added to function mtk_hdmi_bridge_mode_valid()
in order to address possible issues on MT8167;
moreover, with commit c91026a938c2
("drm/mediatek: hdmi: Add optional limit on maximal HDMI mode clock")
another similar check was introduced.

Unfortunately though, at the time of writing, MT8173 does not provide
any mtk_hdmi_conf structure and this is crashing the kernel with NULL
pointer upon entering mtk_hdmi_bridge_mode_valid(), which happens as
soon as a HDMI cable gets plugged in.

To fix this regression, add a NULL pointer check for hdmi-&gt;conf in the
said function, restoring HDMI functionality and avoiding NULL pointer
kernel panics.</Note>
    </Notes>
    <CVE>CVE-2021-47108</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: musb: tusb6010: check return value after calling platform_get_resource()

It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.</Note>
    </Notes>
    <CVE>CVE-2021-47181</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: core: Fix scsi_mode_sense() buffer length handling

Several problems exist with scsi_mode_sense() buffer length handling:

 1) The allocation length field of the MODE SENSE(10) command is 16-bits,
    occupying bytes 7 and 8 of the CDB. With this command, access to mode
    pages larger than 255 bytes is thus possible. However, the CDB
    allocation length field is set by assigning len to byte 8 only, thus
    truncating buffer length larger than 255.

 2) If scsi_mode_sense() is called with len smaller than 8 with
    sdev-&gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length
    is increased to 8 and 4 respectively, and the buffer is zero filled
    with these increased values, thus corrupting the memory following the
    buffer.

Fix these 2 problems by using put_unaligned_be16() to set the allocation
length field of MODE SENSE(10) CDB and by returning an error when len is
too small.

Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
even if the device driver did not set sdev-&gt;use_10_for_ms. In case of
invalid opcode error for MODE SENSE(10), access to mode pages larger than
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
bytes.

While at it, also fix the folowing:

 * Use get_unaligned_be16() to retrieve the mode data length and block
   descriptor length fields of the mode sense reply header instead of using
   an open coded calculation.

 * Fix the kdoc dbd argument explanation: the DBD bit stands for Disable
   Block Descriptor, which is the opposite of what the dbd argument
   description was.</Note>
    </Notes>
    <CVE>CVE-2021-47182</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Fix link down processing to address NULL pointer dereference

If an FC link down transition while PLOGIs are outstanding to fabric well
known addresses, outstanding ABTS requests may result in a NULL pointer
dereference. Driver unload requests may hang with repeated "2878" log
messages.

The Link down processing results in ABTS requests for outstanding ELS
requests. The Abort WQEs are sent for the ELSs before the driver had set
the link state to down. Thus the driver is sending the Abort with the
expectation that an ABTS will be sent on the wire. The Abort request is
stalled waiting for the link to come up. In some conditions the driver may
auto-complete the ELSs thus if the link does come up, the Abort completions
may reference an invalid structure.

Fix by ensuring that Abort set the flag to avoid link traffic if issued due
to conditions where the link failed.</Note>
    </Notes>
    <CVE>CVE-2021-47183</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

i40e: Fix NULL ptr dereference on VSI filter sync

Remove the reason of null pointer dereference in sync VSI filters.
Added new I40E_VSI_RELEASING flag to signalize deleting and releasing
of VSI resources to sync this thread with sync filters subtask.
Without this patch it is possible to start update the VSI filter list
after VSI is removed, that's causing a kernel oops.</Note>
    </Notes>
    <CVE>CVE-2021-47184</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc

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

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

In the testcase pty04, The first process call the write syscall to send
data to the pty master. At the same time, the workqueue will do the
flush_to_ldisc to pop data in a loop until there is no more data left.
When the sender and workqueue running in different core, the sender sends
data fastly in full time which will result in workqueue doing work in loop
for a long time and occuring softlockup in flush_to_ldisc with kernel
configured without preempt. So I add need_resched check and cond_resched
in the flush_to_ldisc loop to avoid it.</Note>
    </Notes>
    <CVE>CVE-2021-47185</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arm64: dts: qcom: msm8998: Fix CPU/L2 idle state latency and residency

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

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

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

scsi: ufs: core: Improve SCSI abort handling

The following has been observed on a test setup:

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

That warning is triggered by the following statement:

	WARN_ON(lrbp-&gt;cmd);

Fix this warning by clearing lrbp-&gt;cmd from the abort handler.</Note>
    </Notes>
    <CVE>CVE-2021-47188</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix memory ordering between normal and ordered work functions

Ordered work functions aren't guaranteed to be handled by the same thread
which executed the normal work functions. The only way execution between
normal/ordered functions is synchronized is via the WORK_DONE_BIT,
unfortunately the used bitops don't guarantee any ordering whatsoever.

This manifested as seemingly inexplicable crashes on ARM64, where
async_chunk::inode is seen as non-null in async_cow_submit which causes
submit_compressed_extents to be called and crash occurs because
async_chunk::inode suddenly became NULL. The call trace was similar to:

    pc : submit_compressed_extents+0x38/0x3d0
    lr : async_cow_submit+0x50/0xd0
    sp : ffff800015d4bc20

    &lt;registers omitted for brevity&gt;

    Call trace:
     submit_compressed_extents+0x38/0x3d0
     async_cow_submit+0x50/0xd0
     run_ordered_work+0xc8/0x280
     btrfs_work_helper+0x98/0x250
     process_one_work+0x1f0/0x4ac
     worker_thread+0x188/0x504
     kthread+0x110/0x114
     ret_from_fork+0x10/0x18

Fix this by adding respective barrier calls which ensure that all
accesses preceding setting of WORK_DONE_BIT are strictly ordered before
setting the flag. At the same time add a read barrier after reading of
WORK_DONE_BIT in run_ordered_work which ensures all subsequent loads
would be strictly ordered after reading the bit. This in turn ensures
are all accesses before WORK_DONE_BIT are going to be strictly ordered
before any access that can occur in ordered_func.</Note>
    </Notes>
    <CVE>CVE-2021-47189</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: scsi_debug: Fix out-of-bound read in resp_readcap16()

The following warning was observed running syzkaller:

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

This issue can be reproduced with the following syzkaller log:

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

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

To solve this issue, define alloc_len as u32.</Note>
    </Notes>
    <CVE>CVE-2021-47191</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: core: sysfs: Fix hang when device state is set via sysfs

This fixes a regression added with:

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

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

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

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

This also adds a check for if we are already in the running state. This
prevents extra scans and helps the iscsid case where if the transport class
has already onlined the device during its recovery process then we don't
need userspace to do it again plus possibly block that daemon.</Note>
    </Notes>
    <CVE>CVE-2021-47192</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: pm80xx: Fix memory leak during rmmod

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

Properly free memory when the module is removed.</Note>
    </Notes>
    <CVE>CVE-2021-47193</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

cfg80211: call cfg80211_stop_ap when switch from P2P_GO type

If the userspace tools switch from NL80211_IFTYPE_P2P_GO to
NL80211_IFTYPE_ADHOC via send_msg(NL80211_CMD_SET_INTERFACE), it
does not call the cleanup cfg80211_stop_ap(), this leads to the
initialization of in-use data. For example, this path re-init the
sdata-&gt;assigned_chanctx_list while it is still an element of
assigned_vifs list, and makes that linked list corrupt.</Note>
    </Notes>
    <CVE>CVE-2021-47194</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 use-after-free of the add_lock mutex

Commit 6098475d4cb4 ("spi: Fix deadlock when adding SPI controllers on
SPI buses") introduced a per-controller mutex. But mutex_unlock() of
said lock is called after the controller is already freed:

  spi_unregister_controller(ctlr)
  -&gt; put_device(&amp;ctlr-&gt;dev)
    -&gt; spi_controller_release(dev)
  -&gt; mutex_unlock(&amp;ctrl-&gt;add_lock)

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

RDMA/core: Set send and receive CQ before forwarding to the driver

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

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

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

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

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

 Freed by task 246:
  kasan_save_stack+0x1b/0x40
  kasan_set_track+0x1c/0x30
  kasan_set_free_info+0x20/0x30
  __kasan_slab_free+0x10c/0x150
  slab_free_freelist_hook+0xb4/0x1b0
  kfree+0xe7/0x2a0
  create_qp.part.0+0x52b/0x6a0 [ib_core]
  ib_create_qp_user+0x97/0x150 [ib_core]
  ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x92c/0x1250 [ib_uverbs]
  ib_uverbs_cmd_verbs+0x1c38/0x3150 [ib_uverbs]
  ib_uverbs_ioctl+0x169/0x260 [ib_uverbs]
  __x64_sys_ioctl+0x866/0x14d0
  do_syscall_64+0x3d/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae</Note>
    </Notes>
    <CVE>CVE-2021-47196</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: nullify cq-&gt;dbg pointer in mlx5_debug_cq_remove()

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

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

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

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

scsi: lpfc: Fix use-after-free in lpfc_unreg_rpi() routine

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

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

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

Fix by clearing the NLP_REG_LOGIN_SEND nlp_flag in
lpfc_mbx_cmpl_fc_reg_login().</Note>
    </Notes>
    <CVE>CVE-2021-47198</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: CT, Fix multiple allocations and memleak of mod acts

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

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

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

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

 backtrace:
    [&lt;000000007316e2f3&gt;] krealloc+0x83/0xd0
    [&lt;00000000ef157de1&gt;] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]
    [&lt;00000000970ce4ae&gt;] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]
    [&lt;0000000067c5fa17&gt;] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]
    [&lt;00000000d032eb98&gt;] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]
    [&lt;00000000fd23b869&gt;] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]
    [&lt;000000004fc24acc&gt;] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]
    [&lt;00000000dc741c17&gt;] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]
    [&lt;00000000e92e49d7&gt;] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core]
    [&lt;00000000f60f5602&gt;] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core]</Note>
    </Notes>
    <CVE>CVE-2021-47199</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap

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

This issue was forseen when the reference dropping was adding in
commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"):
  "For that to work properly the drm_gem_object_get() call in
  drm_gem_ttm_mmap() must be moved so it happens before calling
  obj-&gt;funcs-&gt;mmap(), otherwise the gem refcount would go down
  to zero."</Note>
    </Notes>
    <CVE>CVE-2021-47200</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iavf: free q_vectors before queues in iavf_disable_vf

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

thermal: Fix NULL pointer dereferences in of_thermal_ functions

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

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

While at it, fix the possible NULL pointer dereference in other
functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(),
of_thermal_get_trend().</Note>
    </Notes>
    <CVE>CVE-2021-47202</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq()

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

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

Fix by clearing the fail_msg string after adding a job to the completions
list. This stops the subsequent jobs from being added to the completions
list unless they had an appropriate failure.</Note>
    </Notes>
    <CVE>CVE-2021-47203</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: dpaa2-eth: fix use-after-free in dpaa2_eth_remove

Access to netdev after free_netdev() will cause use-after-free bug.
Move debug log before free_netdev() call to avoid it.</Note>
    </Notes>
    <CVE>CVE-2021-47204</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

clk: sunxi-ng: Unregister clocks/resets when unbinding

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

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

Early OF clock providers are never unregistered, and limited error
handling is possible, so they are mostly unchanged. The error reporting
is made more consistent by moving the message inside of_sunxi_ccu_probe.</Note>
    </Notes>
    <CVE>CVE-2021-47205</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: host: ohci-tmio: check return value after calling platform_get_resource()

It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.</Note>
    </Notes>
    <CVE>CVE-2021-47206</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: gus: fix null pointer dereference on pointer block

The pointer block return from snd_gf1_dma_next_block could be
null, so there is a potential null pointer dereference issue.
Fix this by adding a null check before dereference.</Note>
    </Notes>
    <CVE>CVE-2021-47207</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

sched/fair: Prevent dead task groups from regaining cfs_rq's

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

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

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

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

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

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

usb: typec: tipd: Remove WARN_ON in tps6598x_block_read

Calling tps6598x_block_read with a higher than allowed len can be
handled by just returning an error. There's no need to crash systems
with panic-on-warn enabled.</Note>
    </Notes>
    <CVE>CVE-2021-47210</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb-audio: fix null pointer dereference on pointer cs_desc

The pointer cs_desc return from snd_usb_find_clock_source could
be null, so there is a potential null pointer dereference issue.
Fix this by adding a null check before dereference.</Note>
    </Notes>
    <CVE>CVE-2021-47211</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Update error handler for UCTX and UMEM

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

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

net/mlx5e: kTLS, Fix crash in RX resync flow

For the TLS RX resync flow, we maintain a list of TLS contexts
that require some attention, to communicate their resync information
to the HW.
Here we fix list corruptions, by protecting the entries against
movements coming from resync_handle_seq_match(), until their resync
handling in napi is fully completed.</Note>
    </Notes>
    <CVE>CVE-2021-47215</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: advansys: Fix kernel pointer leak

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

Change %lx to %p to print the hashed pointer.</Note>
    </Notes>
    <CVE>CVE-2021-47216</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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

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

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

selinux: fix NULL-pointer dereference when hashtab allocation fails

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

Fix this by making sure that hashtab_init() always leaves behind a valid
empty hashtab when the allocation fails.</Note>
    </Notes>
    <CVE>CVE-2021-47218</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: scsi_debug: Fix out-of-bound read in resp_report_tgtpgs()

The following issue was observed running syzkaller:

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

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

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

Switch n, alen, and rlen to u32.</Note>
    </Notes>
    <CVE>CVE-2021-47219</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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">** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2021-47469</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

mm, thp: bail out early in collapse_file for writeback page

Currently collapse_file does not explicitly check PG_writeback, instead,
page_has_private and try_to_release_page are used to filter writeback
pages.  This does not work for xfs with blocksize equal to or larger
than pagesize, because in such case xfs has no page-&gt;private.

This makes collapse_file bail out early for writeback page.  Otherwise,
xfs end_page_writeback will panic as follows.

  page:fffffe00201bcc80 refcount:0 mapcount:0 mapping:ffff0003f88c86a8 index:0x0 pfn:0x84ef32
  aops:xfs_address_space_operations [xfs] ino:30000b7 dentry name:"libtest.so"
  flags: 0x57fffe0000008027(locked|referenced|uptodate|active|writeback)
  raw: 57fffe0000008027 ffff80001b48bc28 ffff80001b48bc28 ffff0003f88c86a8
  raw: 0000000000000000 0000000000000000 00000000ffffffff ffff0000c3e9a000
  page dumped because: VM_BUG_ON_PAGE(((unsigned int) page_ref_count(page) + 127u &lt;= 127u))
  page-&gt;mem_cgroup:ffff0000c3e9a000
  ------------[ cut here ]------------
  kernel BUG at include/linux/mm.h:1212!
  Internal error: Oops - BUG: 0 [#1] SMP
  Modules linked in:
  BUG: Bad page state in process khugepaged  pfn:84ef32
   xfs(E)
  page:fffffe00201bcc80 refcount:0 mapcount:0 mapping:0 index:0x0 pfn:0x84ef32
   libcrc32c(E) rfkill(E) aes_ce_blk(E) crypto_simd(E) ...
  CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Tainted: ...
  pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)
  Call trace:
    end_page_writeback+0x1c0/0x214
    iomap_finish_page_writeback+0x13c/0x204
    iomap_finish_ioend+0xe8/0x19c
    iomap_writepage_end_bio+0x38/0x50
    bio_endio+0x168/0x1ec
    blk_update_request+0x278/0x3f0
    blk_mq_end_request+0x34/0x15c
    virtblk_request_done+0x38/0x74 [virtio_blk]
    blk_done_softirq+0xc4/0x110
    __do_softirq+0x128/0x38c
    __irq_exit_rcu+0x118/0x150
    irq_exit+0x1c/0x30
    __handle_domain_irq+0x8c/0xf0
    gic_handle_irq+0x84/0x108
    el1_irq+0xcc/0x180
    arch_cpu_idle+0x18/0x40
    default_idle_call+0x4c/0x1a0
    cpuidle_idle_call+0x168/0x1e0
    do_idle+0xb4/0x104
    cpu_startup_entry+0x30/0x9c
    secondary_start_kernel+0x104/0x180
  Code: d4210000 b0006161 910c8021 94013f4d (d4210000)
  ---[ end trace 4a88c6a074082f8c ]---
  Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt</Note>
    </Notes>
    <CVE>CVE-2021-47492</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

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:

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

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:

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

staging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect()

The free_rtllib() function frees the "dev" pointer so there is use
after free on the next line.  Re-arrange things to avoid that.</Note>
    </Notes>
    <CVE>CVE-2021-47571</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A use-after-free vulnerability was found in rtsx_usb_ms_drv_remove in drivers/memstick/host/rtsx_usb_ms.c in memstick in the Linux kernel. In this flaw, a local attacker with a user privilege may impact system Confidentiality. This flaw affects kernel versions prior to 5.14 rc1.</Note>
    </Notes>
    <CVE>CVE-2022-0487</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>2.1</BaseScore>
        <Vector>AV:L/AC:L/Au:N/C:P/I:N/A:N</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In lock_sock_nested of sock.c, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-174846563References: Upstream kernel</Note>
    </Notes>
    <CVE>CVE-2022-20154</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>4.4</BaseScore>
        <Vector>AV:L/AC:M/Au:N/C:P/I:P/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">xmlparse.c in Expat (aka libexpat) before 2.4.5 allows attackers to insert namespace-separator characters into namespace URIs.</Note>
    </Notes>
    <CVE>CVE-2022-25236</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
    <CVSSScoreSets>
      <ScoreSet>
        <BaseScore>7.5</BaseScore>
        <Vector>AV:N/AC:L/Au:N/C:P/I:P/A:P</Vector>
      </ScoreSet>
    </CVSSScoreSets>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A double-free flaw was found in the Linux kernel's TUN/TAP device driver functionality in how a user registers the device when the register_netdevice function fails (NETDEV_REGISTER notifier). This flaw allows a local user to crash or potentially escalate their privileges on the system.</Note>
    </Notes>
    <CVE>CVE-2022-4744</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 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">close_altfile in filename.c in less before 606 omits shell_quote calls for LESSCLOSE.</Note>
    </Notes>
    <CVE>CVE-2022-48624</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:

vt: fix memory overlapping when deleting chars in the buffer

A memory overlapping copy occurs when deleting a long line. This memory
overlapping copy can cause data corruption when scr_memcpyw is optimized
to memcpy because memcpy does not ensure its behavior if the destination
buffer overlaps with the source buffer. The line buffer is not always
broken, because the memcpy utilizes the hardware acceleration, whose
result is not deterministic.

Fix this problem by using replacing the scr_memcpyw with scr_memmovew.</Note>
    </Notes>
    <CVE>CVE-2022-48627</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qcom-rng - ensure buffer for generate is completely filled

The generate function in struct rng_alg expects that the destination
buffer is completely filled if the function returns 0. qcom_rng_read()
can run into a situation where the buffer is partially filled with
randomness and the remaining part of the buffer is zeroed since
qcom_rng_generate() doesn't check the return value. This issue can
be reproduced by running the following from libkcapi:

    kcapi-rng -b 9000000 &gt; OUTFILE

The generated OUTFILE will have three huge sections that contain all
zeros, and this is caused by the code where the test
'val &amp; PRNG_STATUS_DATA_AVAIL' fails.

Let's fix this issue by ensuring that qcom_rng_read() always returns
with a full buffer if the function returns success. Let's also have
qcom_rng_generate() return the correct value.

Here's some statistics from the ent project
(https://www.fourmilab.ch/random/) that shows information about the
quality of the generated numbers:

    $ ent -c qcom-random-before
    Value Char Occurrences Fraction
      0           606748   0.067416
      1            33104   0.003678
      2            33001   0.003667
    ...
    253   �        32883   0.003654
    254   �        33035   0.003671
    255   �        33239   0.003693

    Total:       9000000   1.000000

    Entropy = 7.811590 bits per byte.

    Optimum compression would reduce the size
    of this 9000000 byte file by 2 percent.

    Chi square distribution for 9000000 samples is 9329962.81, and
    randomly would exceed this value less than 0.01 percent of the
    times.

    Arithmetic mean value of data bytes is 119.3731 (127.5 = random).
    Monte Carlo value for Pi is 3.197293333 (error 1.77 percent).
    Serial correlation coefficient is 0.159130 (totally uncorrelated =
    0.0).

Without this patch, the results of the chi-square test is 0.01%, and
the numbers are certainly not random according to ent's project page.
The results improve with this patch:

    $ ent -c qcom-random-after
    Value Char Occurrences Fraction
      0            35432   0.003937
      1            35127   0.003903
      2            35424   0.003936
    ...
    253   �        35201   0.003911
    254   �        34835   0.003871
    255   �        35368   0.003930

    Total:       9000000   1.000000

    Entropy = 7.999979 bits per byte.

    Optimum compression would reduce the size
    of this 9000000 byte file by 0 percent.

    Chi square distribution for 9000000 samples is 258.77, and randomly
    would exceed this value 42.24 percent of the times.

    Arithmetic mean value of data bytes is 127.5006 (127.5 = random).
    Monte Carlo value for Pi is 3.141277333 (error 0.01 percent).
    Serial correlation coefficient is 0.000468 (totally uncorrelated =
    0.0).

This change was tested on a Nexus 5 phone (msm8974 SoC).</Note>
    </Notes>
    <CVE>CVE-2022-48629</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: qcom-rng - fix infinite loop on requests not multiple of WORD_SZ

The commit referenced in the Fixes tag removed the 'break' from the else
branch in qcom_rng_read(), causing an infinite loop whenever 'max' is
not a multiple of WORD_SZ. This can be reproduced e.g. by running:

    kcapi-rng -b 67 &gt;/dev/null

There are many ways to fix this without adding back the 'break', but
they all seem more awkward than simply adding it back, so do just that.

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

ext4: fix bug in extents parsing when eh_entries == 0 and eh_depth &gt; 0

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

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

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

i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction()

memcpy() is called in a loop while 'operation-&gt;length' upper bound
is not checked and 'data_idx' also increments.</Note>
    </Notes>
    <CVE>CVE-2022-48632</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/gma500: Fix BUG: sleeping function called from invalid context errors

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

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

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

This fixes the following WARN/stacktrace:

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

s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup

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

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

Fix by checking the pavgroup pointer with lcu-&gt;lock held.</Note>
    </Notes>
    <CVE>CVE-2022-48636</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bnxt: prevent skb UAF after handing over to PTP worker

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

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

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

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

sfc: fix TX channel offset when using legacy interrupts

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

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

sfc: fix null pointer dereference in efx_hard_start_xmit

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

I hit this issue because of a different bug that caused tx_queue to be
NULL. If that happens, this is the error message that we get here:
  BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
  [...]
  RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc]</Note>
    </Notes>
    <CVE>CVE-2022-48648</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Fix memory leak in __qlt_24xx_handle_abts()

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

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

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

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

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

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

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

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

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

There are problems if allocated queues less than Traffic Classes.

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

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

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

Only update num_txq/rxq when passed check, and restore tc_cfg if setup
queue map failed.</Note>
    </Notes>
    <CVE>CVE-2022-48652</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ice: Don't double unplug aux on peer initiated reset

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

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

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

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

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

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

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

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

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

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

firmware: arm_scmi: Harden accesses to the reset domains

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

Add an internal consistency check before any such domains descriptors
accesses.</Note>
    </Notes>
    <CVE>CVE-2022-48655</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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

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

arm64: topology: fix possible overflow in amu_fie_setup()

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

Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.</Note>
    </Notes>
    <CVE>CVE-2022-48657</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

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

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

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

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

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

gpio: mockup: fix NULL pointer dereference when removing debugfs

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

smb3: fix temporary data corruption in insert range

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

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

smb3: fix temporary data corruption in collapse range

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

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

cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()

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

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

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

Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.</Note>
    </Notes>
    <CVE>CVE-2022-48672</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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

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

Here is a crash example:

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

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

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

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

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

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

nvme-tcp: fix UAF when detecting digest errors

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

i40e: Fix kernel crash during module removal

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

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

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

Two offline tests cause IRDMA driver failure (ETIMEDOUT) and this
failure is indicated back to i40e_client_subtask() that calls
i40e_client_del_instance() to free client instance referenced
by pf-&gt;cinst and sets this pointer to NULL. During the module
removal i40e_remove() calls i40e_lan_del_device() that dereferences
pf-&gt;cinst that is NULL -&gt; crash.
Do not remove client instance when client open callbacks fails and
just clear __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needs
to take care about this situation (when netdev is up and client
is NOT opened) in i40e_notify_client_of_netdev_close() and
calls client close callback only when __I40E_CLIENT_INSTANCE_OPENED
is set.</Note>
    </Notes>
    <CVE>CVE-2022-48688</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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

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

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

soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs

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

(1) we need to add of_node_put() when for_each__matching_node() breaks
(2) we need to add iounmap() for each iomap in fail path</Note>
    </Notes>
    <CVE>CVE-2022-48693</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/irdma: Fix drain SQ hang with no completion

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

Fix this to generate completions on the right CQ.

[  863.969340] INFO: task kworker/u52:2:671 blocked for more than 122 seconds.
[  863.979224]       Not tainted 5.14.0-130.el9.x86_64 #1
[  863.986588] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  863.996997] task:kworker/u52:2   state:D stack:    0 pid:  671 ppid:     2 flags:0x00004000
[  864.007272] Workqueue: xprtiod xprt_autoclose [sunrpc]
[  864.014056] Call Trace:
[  864.017575]  __schedule+0x206/0x580
[  864.022296]  schedule+0x43/0xa0
[  864.026736]  schedule_timeout+0x115/0x150
[  864.032185]  __wait_for_common+0x93/0x1d0
[  864.037717]  ? usleep_range_state+0x90/0x90
[  864.043368]  __ib_drain_sq+0xf6/0x170 [ib_core]
[  864.049371]  ? __rdma_block_iter_next+0x80/0x80 [ib_core]
[  864.056240]  ib_drain_sq+0x66/0x70 [ib_core]
[  864.062003]  rpcrdma_xprt_disconnect+0x82/0x3b0 [rpcrdma]
[  864.069365]  ? xprt_prepare_transmit+0x5d/0xc0 [sunrpc]
[  864.076386]  xprt_rdma_close+0xe/0x30 [rpcrdma]
[  864.082593]  xprt_autoclose+0x52/0x100 [sunrpc]
[  864.088718]  process_one_work+0x1e8/0x3c0
[  864.094170]  worker_thread+0x50/0x3b0
[  864.099109]  ? rescuer_thread+0x370/0x370
[  864.104473]  kthread+0x149/0x170
[  864.109022]  ? set_kthread_struct+0x40/0x40
[  864.114713]  ret_from_fork+0x22/0x30</Note>
    </Notes>
    <CVE>CVE-2022-48694</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: mpt3sas: Fix use-after-free warning

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

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

nvmet: fix a use-after-free

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

BUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350
Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460
Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop]
Call Trace:
 show_stack+0x52/0x58
 dump_stack_lvl+0x49/0x5e
 print_report.cold+0x36/0x1e2
 kasan_report+0xb9/0xf0
 __asan_load4+0x6b/0x80
 blk_mq_complete_request_remote+0xac/0x350
 nvme_loop_queue_response+0x1df/0x275 [nvme_loop]
 __nvmet_req_complete+0x132/0x4f0 [nvmet]
 nvmet_req_complete+0x15/0x40 [nvmet]
 nvmet_execute_io_connect+0x18a/0x1f0 [nvmet]
 nvme_loop_execute_work+0x20/0x30 [nvme_loop]
 process_one_work+0x56e/0xa70
 worker_thread+0x2d1/0x640
 kthread+0x183/0x1c0
 ret_from_fork+0x1f/0x30</Note>
    </Notes>
    <CVE>CVE-2022-48697</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/debug: fix dentry leak in update_sched_domain_debugfs

Kuyo reports that the pattern of using debugfs_remove(debugfs_lookup())
leaks a dentry and with a hotplug stress test, the machine eventually
runs out of memory.

Fix this up by using the newly created debugfs_lookup_and_remove() call
instead which properly handles the dentry reference counting logic.</Note>
    </Notes>
    <CVE>CVE-2022-48699</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-2022-48700</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: usb-audio: Fix an out-of-bounds bug in __snd_usb_parse_audio_interface()

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

Fix this by checking the number of interfaces.</Note>
    </Notes>
    <CVE>CVE-2022-48701</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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

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

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

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

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

thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR

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

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

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

This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or
NULL value in data_vault.</Note>
    </Notes>
    <CVE>CVE-2022-48703</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

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

Although radeon card fence and wait for gpu to finish processing current batch rings,
there is still a corner case that radeon lockup work queue may not be fully flushed,
and meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to
put device in D3hot state.
Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.
&gt; Configuration and Message requests are the only TLPs accepted by a Function in
&gt; the D3hot state. All other received Requests must be handled as Unsupported Requests,
&gt; and all received Completions may optionally be handled as Unexpected Completions.
This issue will happen in following logs:
Unable to handle kernel paging request at virtual address 00008800e0008010
CPU 0 kworker/0:3(131): Oops 0
pc = [&lt;ffffffff811bea5c&gt;]  ra = [&lt;ffffffff81240844&gt;]  ps = 0000 Tainted: G        W
pc is at si_gpu_check_soft_reset+0x3c/0x240
ra is at si_dma_is_lockup+0x34/0xd0
v0 = 0000000000000000  t0 = fff08800e0008010  t1 = 0000000000010000
t2 = 0000000000008010  t3 = fff00007e3c00000  t4 = fff00007e3c00258
t5 = 000000000000ffff  t6 = 0000000000000001  t7 = fff00007ef078000
s0 = fff00007e3c016e8  s1 = fff00007e3c00000  s2 = fff00007e3c00018
s3 = fff00007e3c00000  s4 = fff00007fff59d80  s5 = 0000000000000000
s6 = fff00007ef07bd98
a0 = fff00007e3c00000  a1 = fff00007e3c016e8  a2 = 0000000000000008
a3 = 0000000000000001  a4 = 8f5c28f5c28f5c29  a5 = ffffffff810f4338
t8 = 0000000000000275  t9 = ffffffff809b66f8  t10 = ff6769c5d964b800
t11= 000000000000b886  pv = ffffffff811bea20  at = 0000000000000000
gp = ffffffff81d89690  sp = 00000000aa814126
Disabling lock debugging due to kernel taint
Trace:
[&lt;ffffffff81240844&gt;] si_dma_is_lockup+0x34/0xd0
[&lt;ffffffff81119610&gt;] radeon_fence_check_lockup+0xd0/0x290
[&lt;ffffffff80977010&gt;] process_one_work+0x280/0x550
[&lt;ffffffff80977350&gt;] worker_thread+0x70/0x7c0
[&lt;ffffffff80977410&gt;] worker_thread+0x130/0x7c0
[&lt;ffffffff80982040&gt;] kthread+0x200/0x210
[&lt;ffffffff809772e0&gt;] worker_thread+0x0/0x7c0
[&lt;ffffffff80981f8c&gt;] kthread+0x14c/0x210
[&lt;ffffffff80911658&gt;] ret_from_kernel_thread+0x18/0x20
[&lt;ffffffff80981e40&gt;] kthread+0x0/0x210
 Code: ad3e0008  43f0074a  ad7e0018  ad9e0020  8c3001e8  40230101
 &lt;88210000&gt; 4821ed21
So force lockup work queue flush to fix this problem.</Note>
    </Notes>
    <CVE>CVE-2022-48704</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 deadlock flaw was found in the Linux kernel's BPF subsystem. This flaw allows a local user to potentially crash the system.</Note>
    </Notes>
    <CVE>CVE-2023-0160</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A use-after-free vulnerability in the Linux Kernel traffic control index filter (tcindex) can be exploited to achieve local privilege escalation.  The tcindex_delete function which does not properly deactivate filters in case of a perfect hashes while deleting the underlying structure which can later lead to double freeing the structure.  A local attacker user can use this vulnerability to elevate its privileges to root.
We recommend upgrading past commit 8c710f75256bb3cf05ac7b1672c82b92c43f3d28.

</Note>
    </Notes>
    <CVE>CVE-2023-1829</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Bluetooth BR/EDR devices with Secure Simple Pairing and Secure Connections pairing in Bluetooth Core Specification 4.2 through 5.4 allow certain man-in-the-middle attacks that force a short key length, and might lead to discovery of the encryption key and live injection, aka BLUFFS.</Note>
    </Notes>
    <CVE>CVE-2023-24023</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The email module of Python through 3.11.3 incorrectly parses e-mail addresses that contain a special character. The wrong portion of an RFC2822 header is identified as the value of the addr-spec. In some applications, an attacker can bypass a protection mechanism in which application access is granted only after verifying receipt of e-mail to a specific domain (e.g., only @company.example.com addresses may be used for signup). This occurs in email/_parseaddr.py in recent versions of Python.</Note>
    </Notes>
    <CVE>CVE-2023-27043</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An out-of-bounds read vulnerability was found in the SR-IPv6 implementation in the Linux kernel. The flaw exists within the processing of seg6 attributes. The issue results from the improper validation of user-supplied data, which can result in a read past the end of an allocated buffer. This flaw allows a privileged local user to disclose sensitive information on affected installations of the Linux kernel.</Note>
    </Notes>
    <CVE>CVE-2023-2860</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Information exposure through microarchitectural state after transient execution from some register files for some Intel(R) Atom(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.</Note>
    </Notes>
    <CVE>CVE-2023-28746</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">An issue was discovered in the Linux kernel through 6.3.8. A use-after-free was found in ravb_remove in drivers/net/ethernet/renesas/ravb_main.c.</Note>
    </Notes>
    <CVE>CVE-2023-35827</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 ** Not a Security Issue.</Note>
    </Notes>
    <CVE>CVE-2023-38288</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in Avahi, where a reachable assertion exists in avahi_dns_packet_append_record.</Note>
    </Notes>
    <CVE>CVE-2023-38469</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in Avahi. A reachable assertion exists in the dbus_set_host_name function.</Note>
    </Notes>
    <CVE>CVE-2023-38471</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">LibTIFF is vulnerable to an integer overflow. This flaw allows remote attackers to cause a denial of service (application crash) or possibly execute an arbitrary code via a crafted tiff image, which triggers a heap-based buffer overflow.</Note>
    </Notes>
    <CVE>CVE-2023-40745</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Sudo before 1.9.15 might allow row hammer attacks (for authentication bypass or privilege escalation) because application logic sometimes is based on not equaling an error value (instead of equaling a success value), and because the values do not resist flips of a single bit.</Note>
    </Notes>
    <CVE>CVE-2023-42465</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The DNS message parsing code in `named` includes a section whose computational complexity is overly high. It does not cause problems for typical DNS traffic, but crafted queries and responses may cause excessive CPU load on the affected `named` instance by exploiting this flaw. This issue affects both authoritative servers and recursive resolvers.
This issue affects BIND 9 versions 9.0.0 through 9.16.45, 9.18.0 through 9.18.21, 9.19.0 through 9.19.19, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.45-S1, and 9.18.11-S1 through 9.18.21-S1.</Note>
    </Notes>
    <CVE>CVE-2023-4408</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.</Note>
    </Notes>
    <CVE>CVE-2023-45288</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.</Note>
    </Notes>
    <CVE>CVE-2023-45918</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">Graphviz 2.36.0 through 9.x before 10.0.1 has an out-of-bounds read via a crafted config6a file. NOTE: exploitability may be uncommon because this file is typically owned by root.</Note>
    </Notes>
    <CVE>CVE-2023-46045</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">Transmit requests in Xen's virtual network protocol can consist of
multiple parts.  While not really useful, except for the initial part
any of them may be of zero length, i.e. carry no data at all.  Besides a
certain initial portion of the to be transferred data, these parts are
directly translated into what Linux calls SKB fragments.  Such converted
request parts can, when for a particular SKB they are all of length
zero, lead to a de-reference of NULL in core networking code.
</Note>
    </Notes>
    <CVE>CVE-2023-46838</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Recent x86 CPUs offer functionality named Control-flow Enforcement
Technology (CET).  A sub-feature of this are Shadow Stacks (CET-SS).
CET-SS is a hardware feature designed to protect against Return Oriented
Programming attacks. When enabled, traditional stacks holding both data
and return addresses are accompanied by so called "shadow stacks",
holding little more than return addresses.  Shadow stacks aren't
writable by normal instructions, and upon function returns their
contents are used to check for possible manipulation of a return address
coming from the traditional stack.

In particular certain memory accesses need intercepting by Xen.  In
various cases the necessary emulation involves kind of replaying of
the instruction.  Such replaying typically involves filling and then
invoking of a stub.  Such a replayed instruction may raise an
exceptions, which is expected and dealt with accordingly.

Unfortunately the interaction of both of the above wasn't right:
Recovery involves removal of a call frame from the (traditional) stack.
The counterpart of this operation for the shadow stack was missing.
</Note>
    </Notes>
    <CVE>CVE-2023-46841</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">The brcm80211 component in the Linux kernel through 6.5.10 has a brcmf_cfg80211_detach use-after-free in the device unplugging (disconnect the USB by hotplug) code. For physically proximate attackers with local access, this "could be exploited in a real world scenario." This is related to brcmf_cfg80211_escan_timeout_worker in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c.</Note>
    </Notes>
    <CVE>CVE-2023-47233</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Use After Free in GitHub repository vim/vim prior to 9.0.1857.</Note>
    </Notes>
    <CVE>CVE-2023-4750</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">Vim is an open source command line text editor. When closing a window, vim may try to access already freed window structure. Exploitation beyond crashing the application has not been shown to be viable. This issue has been addressed in commit `25aabc2b` which has been included in release version 9.0.2106. Users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2023-48231</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">Vim is an open source command line text editor. A floating point exception may occur when calculating the line offset for overlong lines and smooth scrolling is enabled and the cpo-settings include the 'n' flag. This may happen when a window border is present and when the wrapped line continues on the next physical line directly in the window border because the 'cpo' setting includes the 'n' flag. Only users with non-default settings are affected and the exception should only result in a crash. This issue has been addressed in commit `cb0b99f0` which has been included in release version 9.0.2107. Users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2023-48232</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">Vim is an open source command line text editor. If the count after the :s command is larger than what fits into a (signed) long variable, abort with e_value_too_large. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `ac6378773` which has been included in release version 9.0.2108. Users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2023-48233</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">Vim is an open source command line text editor. When getting the count for a normal mode z command, it may overflow for large counts given. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `58f9befca1` which has been included in release version 9.0.2109. Users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2023-48234</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">Vim is an open source command line text editor. When parsing relative ex addresses one may unintentionally cause an
overflow. Ironically this happens in the existing overflow check, because the line number becomes negative and LONG_MAX - lnum will cause the overflow. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `060623e` which has been included in release version 9.0.2110. Users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2023-48235</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">Vim is an open source command line text editor. When using the z= command, the user may overflow the count with values larger
than MAX_INT. Impact is low, user interaction is required and a crash may not even happen in all situations. This vulnerability has been addressed in commit `73b2d379` which has been included in release version 9.0.2111. Users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2023-48236</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">Vim is an open source command line text editor. In affected versions when shifting lines in operator pending mode and using a very large value, it may be possible to overflow the size of integer. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `6bf131888` which has been included in version 9.0.2112. Users are advised to upgrade. There are no known workarounds for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2023-48237</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">Vim is a UNIX editor that, prior to version 9.0.2121, has a heap-use-after-free vulnerability. When executing a `:s` command for the very first time and using a sub-replace-special atom inside the substitution part, it is possible that the recursive `:s` call causes free-ing of memory which may later then be accessed by the initial `:s` command. The user must intentionally execute the payload and the whole process is a bit tricky to do since it seems to work only reliably for the very first :s command. It may also cause a crash of Vim. Version 9.0.2121 contains a fix for this issue.</Note>
    </Notes>
    <CVE>CVE-2023-48706</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.</Note>
    </Notes>
    <CVE>CVE-2023-48795</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">** REJECT ** CVE-2023-4881 was wrongly assigned to a bug that was deemed to be a non-security issue by the Linux kernel security team.</Note>
    </Notes>
    <CVE>CVE-2023-4881</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A use-after-free vulnerability in the Linux kernel's net/sched: sch_qfq component can be exploited to achieve local privilege escalation.

When the plug qdisc is used as a class of the qfq qdisc, sending network packets triggers use-after-free in qfq_dequeue() due to the incorrect .peek handler of sch_plug and lack of error checking in agg_dequeue().

We recommend upgrading past commit 8fc134fee27f2263988ae38920bc03da416b03d8.

</Note>
    </Notes>
    <CVE>CVE-2023-4921</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">Certain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035, 6840, and related RFCs) allow remote attackers to cause a denial of service (CPU consumption) via one or more DNSSEC responses, aka the "KeyTrap" issue. One of the concerns is that, when there is a zone with many DNSKEY and RRSIG records, the protocol specification implies that an algorithm must evaluate all combinations of DNSKEY and RRSIG records.</Note>
    </Notes>
    <CVE>CVE-2023-50387</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The Closest Encloser Proof aspect of the DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows remote attackers to cause a denial of service (CPU consumption for SHA-1 computations) via DNSSEC responses in a random subdomain attack, aka the "NSEC3" issue. The RFC 5155 specification implies that an algorithm must perform thousands of iterations of a hash function in certain situations.</Note>
    </Notes>
    <CVE>CVE-2023-50868</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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 before 6.4.12, amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c has a fence use-after-free.</Note>
    </Notes>
    <CVE>CVE-2023-51042</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel before 6.4.5, drivers/gpu/drm/drm_atomic.c has a use-after-free during a race condition between a nonblocking atomic commit and a driver unload.</Note>
    </Notes>
    <CVE>CVE-2023-51043</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In ssh in OpenSSH before 9.6, OS command injection might occur if a user name or host name has shell metacharacters, and this name is referenced by an expansion token in certain situations. For example, an untrusted Git repository can have a submodule with shell metacharacters in a user name or host name.</Note>
    </Notes>
    <CVE>CVE-2023-51385</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was discovered in the Linux kernel before 6.6.8. do_vcc_ioctl in net/atm/ioctl.c has a use-after-free because of a vcc_recvmsg race condition.</Note>
    </Notes>
    <CVE>CVE-2023-51780</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was discovered in the Linux kernel before 6.6.8. rose_ioctl in net/rose/af_rose.c has a use-after-free because of a rose_accept race condition.</Note>
    </Notes>
    <CVE>CVE-2023-51782</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.

Addition and removal of rules from chain bindings within the same transaction causes leads to use-after-free.

We recommend upgrading past commit f15f29fd4779be8a418b66e9d52979bb6d6c2325.

</Note>
    </Notes>
    <CVE>CVE-2023-5197</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">PyCryptodome and pycryptodomex before 3.19.1 allow side-channel leakage for OAEP decryption, exploitable for a Manger attack.</Note>
    </Notes>
    <CVE>CVE-2023-52323</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The IPv6 implementation in the Linux kernel before 6.3 has a net/ipv6/route.c max_size threshold that can be consumed easily, e.g., leading to a denial of service (network is unreachable errors) when IPv6 packets are sent in a loop via a raw socket.</Note>
    </Notes>
    <CVE>CVE-2023-52340</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 segment fault (SEGV) flaw was found in libtiff that could be triggered by passing a crafted tiff file to the TIFFReadRGBATileExt() API. This flaw allows a remote attacker to cause a heap-buffer overflow, leading to a denial of service.</Note>
    </Notes>
    <CVE>CVE-2023-52356</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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">dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct dm_ioctl.target_count.</Note>
    </Notes>
    <CVE>CVE-2023-52429</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

uio: Fix use-after-free in uio_open

core-1				core-2
-------------------------------------------------------
uio_unregister_device		uio_open
				idev = idr_find()
device_unregister(&amp;idev-&gt;dev)
put_device(&amp;idev-&gt;dev)
uio_device_release
				get_device(&amp;idev-&gt;dev)
kfree(idev)
uio_free_minor(minor)
				uio_release
				put_device(&amp;idev-&gt;dev)
				kfree(idev)
-------------------------------------------------------

In the core-1 uio_unregister_device(), the device_unregister will kfree
idev when the idev-&gt;dev kobject ref is 1. But after core-1
device_unregister, put_device and before doing kfree, the core-2 may
get_device. Then:
1. After core-1 kfree idev, the core-2 will do use-after-free for idev.
2. When core-2 do uio_release and put_device, the idev will be double
   freed.

To address this issue, we can get idev atomic &amp; inc idev reference with
minor_lock.</Note>
    </Notes>
    <CVE>CVE-2023-52439</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

apparmor: avoid crash when parsed profile name is empty

When processing a packed profile in unpack_profile() described like

 "profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}"

a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then
passed to aa_splitn_fqname().

aa_splitn_fqname() treats ":samba-dcerpcd" as only containing a namespace.
Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later
aa_alloc_profile() crashes as the new profile name is NULL now.

general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
RIP: 0010:strlen+0x1e/0xa0
Call Trace:
 &lt;TASK&gt;
 ? strlen+0x1e/0xa0
 aa_policy_init+0x1bb/0x230
 aa_alloc_profile+0xb1/0x480
 unpack_profile+0x3bc/0x4960
 aa_unpack+0x309/0x15e0
 aa_replace_profiles+0x213/0x33c0
 policy_update+0x261/0x370
 profile_replace+0x20e/0x2a0
 vfs_write+0x2af/0xe00
 ksys_write+0x126/0x250
 do_syscall_64+0x46/0xf0
 entry_SYSCALL_64_after_hwframe+0x6e/0x76
 &lt;/TASK&gt;
---[ end trace 0000000000000000 ]---
RIP: 0010:strlen+0x1e/0xa0

It seems such behaviour of aa_splitn_fqname() is expected and checked in
other places where it is called (e.g. aa_remove_profiles). Well, there
is an explicit comment "a ns name without a following profile is allowed"
inside.

AFAICS, nothing can prevent unpacked "name" to be in form like
":samba-dcerpcd" - it is passed from userspace.

Deny the whole profile set replacement in such case and inform user with
EPROTO and an explaining message.

Found by Linux Verification Center (linuxtesting.org).</Note>
    </Notes>
    <CVE>CVE-2023-52443</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

media: pvrusb2: fix use after free on context disconnection

Upon module load, a kthread is created targeting the
pvr2_context_thread_func function, which may call pvr2_context_destroy
and thus call kfree() on the context object. However, that might happen
before the usb hub_event handler is able to notify the driver. This
patch adds a sanity check before the invalid read reported by syzbot,
within the context disconnection call stack.</Note>
    </Notes>
    <CVE>CVE-2023-52445</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Defer the free of inner map when necessary

When updating or deleting an inner map in map array or map htab, the map
may still be accessed by non-sleepable program or sleepable program.
However bpf_map_fd_put_ptr() decreases the ref-counter of the inner map
directly through bpf_map_put(), if the ref-counter is the last one
(which is true for most cases), the inner map will be freed by
ops-&gt;map_free() in a kworker. But for now, most .map_free() callbacks
don't use synchronize_rcu() or its variants to wait for the elapse of a
RCU grace period, so after the invocation of ops-&gt;map_free completes,
the bpf program which is accessing the inner map may incur
use-after-free problem.

Fix the free of inner map by invoking bpf_map_free_deferred() after both
one RCU grace period and one tasks trace RCU grace period if the inner
map has been removed from the outer map before. The deferment is
accomplished by using call_rcu() or call_rcu_tasks_trace() when
releasing the last ref-counter of bpf map. The newly-added rcu_head
field in bpf_map shares the same storage space with work field to
reduce the size of bpf_map.</Note>
    </Notes>
    <CVE>CVE-2023-52447</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump

Syzkaller has reported a NULL pointer dereference when accessing
rgd-&gt;rd_rgl in gfs2_rgrp_dump().  This can happen when creating
rgd-&gt;rd_gl fails in read_rindex_entry().  Add a NULL pointer check in
gfs2_rgrp_dump() to prevent that.</Note>
    </Notes>
    <CVE>CVE-2023-52448</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mtd: Fix gluebi NULL pointer dereference caused by ftl notifier

If both ftl.ko and gluebi.ko are loaded, the notifier of ftl
triggers NULL pointer dereference when trying to access
'gluebi-&gt;desc' in gluebi_read().

ubi_gluebi_init
  ubi_register_volume_notifier
    ubi_enumerate_volumes
      ubi_notify_all
        gluebi_notify    nb-&gt;notifier_call()
          gluebi_create
            mtd_device_register
              mtd_device_parse_register
                add_mtd_device
                  blktrans_notify_add   not-&gt;add()
                    ftl_add_mtd         tr-&gt;add_mtd()
                      scan_header
                        mtd_read
                          mtd_read_oob
                            mtd_read_oob_std
                              gluebi_read   mtd-&gt;read()
                                gluebi-&gt;desc - NULL

Detailed reproduction information available at the Link [1],

In the normal case, obtain gluebi-&gt;desc in the gluebi_get_device(),
and access gluebi-&gt;desc in the gluebi_read(). However,
gluebi_get_device() is not executed in advance in the
ftl_add_mtd() process, which leads to NULL pointer dereference.

The solution for the gluebi module is to run jffs2 on the UBI
volume without considering working with ftl or mtdblock [2].
Therefore, this problem can be avoided by preventing gluebi from
creating the mtdblock device after creating mtd partition of the
type MTD_UBIVOLUME.</Note>
    </Notes>
    <CVE>CVE-2023-52449</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

perf/x86/intel/uncore: Fix NULL pointer dereference issue in upi_fill_topology()

Get logical socket id instead of physical id in discover_upi_topology()
to avoid out-of-bound access on 'upi = &amp;type-&gt;topology[nid][idx];' line
that leads to NULL pointer dereference in upi_fill_topology()</Note>
    </Notes>
    <CVE>CVE-2023-52450</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/memhp: Fix access beyond end of drmem array

dlpar_memory_remove_by_index() may access beyond the bounds of the
drmem lmb array when the LMB lookup fails to match an entry with the
given DRC index. When the search fails, the cursor is left pointing to
&amp;drmem_info-&gt;lmbs[drmem_info-&gt;n_lmbs], which is one element past the
last valid entry in the array. The debug message at the end of the
function then dereferences this pointer:

        pr_debug("Failed to hot-remove memory at %llx\n",
                 lmb-&gt;base_addr);

This was found by inspection and confirmed with KASAN:

  pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234
  ==================================================================
  BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658
  Read of size 8 at addr c000000364e97fd0 by task bash/949

  dump_stack_lvl+0xa4/0xfc (unreliable)
  print_report+0x214/0x63c
  kasan_report+0x140/0x2e0
  __asan_load8+0xa8/0xe0
  dlpar_memory+0x298/0x1658
  handle_dlpar_errorlog+0x130/0x1d0
  dlpar_store+0x18c/0x3e0
  kobj_attr_store+0x68/0xa0
  sysfs_kf_write+0xc4/0x110
  kernfs_fop_write_iter+0x26c/0x390
  vfs_write+0x2d4/0x4e0
  ksys_write+0xac/0x1a0
  system_call_exception+0x268/0x530
  system_call_vectored_common+0x15c/0x2ec

  Allocated by task 1:
   kasan_save_stack+0x48/0x80
   kasan_set_track+0x34/0x50
   kasan_save_alloc_info+0x34/0x50
   __kasan_kmalloc+0xd0/0x120
   __kmalloc+0x8c/0x320
   kmalloc_array.constprop.0+0x48/0x5c
   drmem_init+0x2a0/0x41c
   do_one_initcall+0xe0/0x5c0
   kernel_init_freeable+0x4ec/0x5a0
   kernel_init+0x30/0x1e0
   ret_from_kernel_user_thread+0x14/0x1c

  The buggy address belongs to the object at c000000364e80000
   which belongs to the cache kmalloc-128k of size 131072
  The buggy address is located 0 bytes to the right of
   allocated 98256-byte region [c000000364e80000, c000000364e97fd0)

  ==================================================================
  pseries-hotplug-mem: Failed to hot-remove memory at 0

Log failed lookups with a separate message and dereference the
cursor only when it points to a valid entry.</Note>
    </Notes>
    <CVE>CVE-2023-52451</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix accesses to uninit stack slots

Privileged programs are supposed to be able to read uninitialized stack
memory (ever since 6715df8d5) but, before this patch, these accesses
were permitted inconsistently. In particular, accesses were permitted
above state-&gt;allocated_stack, but not below it. In other words, if the
stack was already "large enough", the access was permitted, but
otherwise the access was rejected instead of being allowed to "grow the
stack". This undesired rejection was happening in two places:
- in check_stack_slot_within_bounds()
- in check_stack_range_initialized()
This patch arranges for these accesses to be permitted. A bunch of tests
that were relying on the old rejection had to change; all of them were
changed to add also run unprivileged, in which case the old behavior
persists. One tests couldn't be updated - global_func16 - because it
can't run unprivileged for other reasons.

This patch also fixes the tracking of the stack size for variable-offset
reads. This second fix is bundled in the same commit as the first one
because they're inter-related. Before this patch, writes to the stack
using registers containing a variable offset (as opposed to registers
with fixed, known values) were not properly contributing to the
function's needed stack size. As a result, it was possible for a program
to verify, but then to attempt to read out-of-bounds data at runtime
because a too small stack had been allocated for it.

Each function tracks the size of the stack it needs in
bpf_subprog_info.stack_depth, which is maintained by
update_stack_depth(). For regular memory accesses, check_mem_access()
was calling update_state_depth() but it was passing in only the fixed
part of the offset register, ignoring the variable offset. This was
incorrect; the minimum possible value of that register should be used
instead.

This tracking is now fixed by centralizing the tracking of stack size in
grow_stack_state(), and by lifting the calls to grow_stack_state() to
check_stack_access_within_bounds() as suggested by Andrii. The code is
now simpler and more convincingly tracks the correct maximum stack size.
check_stack_range_initialized() can now rely on enough stack having been
allocated for the access; this helps with the fix for the first issue.

A few tests were changed to also check the stack depth computation. The
one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.</Note>
    </Notes>
    <CVE>CVE-2023-52452</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

serial: imx: fix tx statemachine deadlock

When using the serial port as RS485 port, the tx statemachine is used to
control the RTS pin to drive the RS485 transceiver TX_EN pin. When the
TTY port is closed in the middle of a transmission (for instance during
userland application crash), imx_uart_shutdown disables the interface
and disables the Transmission Complete interrupt. afer that,
imx_uart_stop_tx bails on an incomplete transmission, to be retriggered
by the TC interrupt. This interrupt is disabled and therefore the tx
statemachine never transitions out of SEND. The statemachine is in
deadlock now, and the TX_EN remains low, making the interface useless.

imx_uart_stop_tx now checks for incomplete transmission AND whether TC
interrupts are enabled before bailing to be retriggered. This makes sure
the state machine handling is reached, and is properly set to
WAIT_AFTER_SEND.</Note>
    </Notes>
    <CVE>CVE-2023-52456</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: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failed

Returning an error code from .remove() makes the driver core emit the
little helpful error message:

	remove callback returned a non-zero value. This will be ignored.

and then remove the device anyhow. So all resources that were not freed
are leaked in this case. Skipping serial8250_unregister_port() has the
potential to keep enough of the UART around to trigger a use-after-free.

So replace the error return (and with it the little helpful error
message) by a more useful error message and continue to cleanup.</Note>
    </Notes>
    <CVE>CVE-2023-52457</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

efivarfs: force RO when remounting if SetVariable is not supported

If SetVariable at runtime is not supported by the firmware we never assign
a callback for that function. At the same time mount the efivarfs as
RO so no one can call that.  However, we never check the permission flags
when someone remounts the filesystem as RW. As a result this leads to a
crash looking like this:

$ mount -o remount,rw /sys/firmware/efi/efivars
$ efi-updatevar -f PK.auth PK

[  303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[  303.280482] Mem abort info:
[  303.280854]   ESR = 0x0000000086000004
[  303.281338]   EC = 0x21: IABT (current EL), IL = 32 bits
[  303.282016]   SET = 0, FnV = 0
[  303.282414]   EA = 0, S1PTW = 0
[  303.282821]   FSC = 0x04: level 0 translation fault
[  303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000
[  303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
[  303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP
[  303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6
[  303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1
[  303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023
[  303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  303.292123] pc : 0x0
[  303.292443] lr : efivar_set_variable_locked+0x74/0xec
[  303.293156] sp : ffff800008673c10
[  303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000
[  303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027
[  303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000
[  303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000
[  303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54
[  303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4
[  303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002
[  303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201
[  303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc
[  303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000
[  303.303341] Call trace:
[  303.303679]  0x0
[  303.303938]  efivar_entry_set_get_size+0x98/0x16c
[  303.304585]  efivarfs_file_write+0xd0/0x1a4
[  303.305148]  vfs_write+0xc4/0x2e4
[  303.305601]  ksys_write+0x70/0x104
[  303.306073]  __arm64_sys_write+0x1c/0x28
[  303.306622]  invoke_syscall+0x48/0x114
[  303.307156]  el0_svc_common.constprop.0+0x44/0xec
[  303.307803]  do_el0_svc+0x38/0x98
[  303.308268]  el0_svc+0x2c/0x84
[  303.308702]  el0t_64_sync_handler+0xf4/0x120
[  303.309293]  el0t_64_sync+0x190/0x194
[  303.309794] Code: ???????? ???????? ???????? ???????? (????????)
[  303.310612] ---[ end trace 0000000000000000 ]---

Fix this by adding a .reconfigure() function to the fs operations which
we can use to check the requested flags and deny anything that's not RO
if the firmware doesn't implement SetVariable at runtime.</Note>
    </Notes>
    <CVE>CVE-2023-52463</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

EDAC/thunderx: Fix possible out-of-bounds string access

Enabling -Wstringop-overflow globally exposes a warning for a common bug
in the usage of strncat():

  drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr':
  drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=]
   1136 |                 strncat(msg, other, OCX_MESSAGE_SIZE);
        |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   ...
   1145 |                                 strncat(msg, other, OCX_MESSAGE_SIZE);
   ...
   1150 |                                 strncat(msg, other, OCX_MESSAGE_SIZE);

   ...

Apparently the author of this driver expected strncat() to behave the
way that strlcat() does, which uses the size of the destination buffer
as its third argument rather than the length of the source buffer. The
result is that there is no check on the size of the allocated buffer.

Change it to strlcat().

  [ bp: Trim compiler output, fixup commit message. ]</Note>
    </Notes>
    <CVE>CVE-2023-52464</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

mfd: syscon: Fix null pointer dereference in of_syscon_register()

kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.</Note>
    </Notes>
    <CVE>CVE-2023-52467</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/amd/pm: fix a use-after-free in kv_parse_power_table

When ps allocated by kzalloc equals to NULL, kv_parse_power_table
frees adev-&gt;pm.dpm.ps that allocated before. However, after the control
flow goes through the following call chains:

kv_parse_power_table
  |-&gt; kv_dpm_init
        |-&gt; kv_dpm_sw_init
	      |-&gt; kv_dpm_fini

The adev-&gt;pm.dpm.ps is used in the for loop of kv_dpm_fini after its
first free in kv_parse_power_table and causes a use-after-free bug.</Note>
    </Notes>
    <CVE>CVE-2023-52469</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/radeon: check the alloc_workqueue return value in radeon_crtc_init()

check the alloc_workqueue return value in radeon_crtc_init()
to avoid null-ptr-deref.</Note>
    </Notes>
    <CVE>CVE-2023-52470</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests

hfi1 user SDMA request processing has two bugs that can cause data
corruption for user SDMA requests that have multiple payload iovecs
where an iovec other than the tail iovec does not run up to the page
boundary for the buffer pointed to by that iovec.a

Here are the specific bugs:
1. user_sdma_txadd() does not use struct user_sdma_iovec-&gt;iov.iov_len.
   Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec
   to the packet, even if some of those bytes are past
   iovec-&gt;iov.iov_len and are thus not intended to be in the packet.
2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the
   next iovec in user_sdma_request-&gt;iovs when the current iovec
   is not PAGE_SIZE and does not contain enough data to complete the
   packet. The transmitted packet will contain the wrong data from the
   iovec pages.

This has not been an issue with SDMA packets from hfi1 Verbs or PSM2
because they only produce iovecs that end short of PAGE_SIZE as the tail
iovec of an SDMA request.

Fixing these bugs exposes other bugs with the SDMA pin cache
(struct mmu_rb_handler) that get in way of supporting user SDMA requests
with multiple payload iovecs whose buffers do not end at PAGE_SIZE. So
this commit fixes those issues as well.

Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovec
payload user SDMA requests can hit:
1. Overlapping memory ranges in mmu_rb_handler will result in duplicate
   pinnings.
2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node),
   the mmu_rb code (1) removes the existing entry under a lock, (2)
   releases that lock, pins the new pages, (3) then reacquires the lock
   to insert the extended mmu_rb_node.

   If someone else comes in and inserts an overlapping entry between (2)
   and (3), insert in (3) will fail.

   The failure path code in this case unpins _all_ pages in either the
   original mmu_rb_node or the new mmu_rb_node that was inserted between
   (2) and (3).
3. In hfi1_mmu_rb_remove_unless_exact(), mmu_rb_node-&gt;refcount is
   incremented outside of mmu_rb_handler-&gt;lock. As a result, mmu_rb_node
   could be evicted by another thread that gets mmu_rb_handler-&gt;lock and
   checks mmu_rb_node-&gt;refcount before mmu_rb_node-&gt;refcount is
   incremented.
4. Related to #2 above, SDMA request submission failure path does not
   check mmu_rb_node-&gt;refcount before freeing mmu_rb_node object.

   If there are other SDMA requests in progress whose iovecs have
   pointers to the now-freed mmu_rb_node(s), those pointers to the
   now-freed mmu_rb nodes will be dereferenced when those SDMA requests
   complete.</Note>
    </Notes>
    <CVE>CVE-2023-52474</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: powermate - fix use-after-free in powermate_config_complete

syzbot has found a use-after-free bug [1] in the powermate driver. This
happens when the device is disconnected, which leads to a memory free from
the powermate_device struct.  When an asynchronous control message
completes after the kfree and its callback is invoked, the lock does not
exist anymore and hence the bug.

Use usb_kill_urb() on pm-&gt;config to cancel any in-progress requests upon
device disconnection.

[1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e</Note>
    </Notes>
    <CVE>CVE-2023-52475</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

perf/x86/lbr: Filter vsyscall addresses

We found that a panic can occur when a vsyscall is made while LBR sampling
is active. If the vsyscall is interrupted (NMI) for perf sampling, this
call sequence can occur (most recent at top):

    __insn_get_emulate_prefix()
    insn_get_emulate_prefix()
    insn_get_prefixes()
    insn_get_opcode()
    decode_branch_type()
    get_branch_type()
    intel_pmu_lbr_filter()
    intel_pmu_handle_irq()
    perf_event_nmi_handler()

Within __insn_get_emulate_prefix() at frame 0, a macro is called:

    peek_nbyte_next(insn_byte_t, insn, i)

Within this macro, this dereference occurs:

    (insn)-&gt;next_byte

Inspecting registers at this point, the value of the next_byte field is the
address of the vsyscall made, for example the location of the vsyscall
version of gettimeofday() at 0xffffffffff600000. The access to an address
in the vsyscall region will trigger an oops due to an unhandled page fault.

To fix the bug, filtering for vsyscalls can be done when
determining the branch type. This patch will return
a "none" branch if a kernel address if found to lie in the
vsyscall region.</Note>
    </Notes>
    <CVE>CVE-2023-52476</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: hub: Guard against accesses to uninitialized BOS descriptors

Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
access fields inside udev-&gt;bos without checking if it was allocated and
initialized. If usb_get_bos_descriptor() fails for whatever
reason, udev-&gt;bos will be NULL and those accesses will result in a
crash:

BUG: kernel NULL pointer dereference, address: 0000000000000018
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 &lt;HASH:1f9e 1&gt;
Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021
Workqueue: usb_hub_wq hub_event
RIP: 0010:hub_port_reset+0x193/0x788
Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 &lt;48&gt; 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9
RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310
RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840
RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0
Call Trace:
hub_event+0x73f/0x156e
? hub_activate+0x5b7/0x68f
process_one_work+0x1a2/0x487
worker_thread+0x11a/0x288
kthread+0x13a/0x152
? process_one_work+0x487/0x487
? kthread_associate_blkcg+0x70/0x70
ret_from_fork+0x1f/0x30

Fall back to a default behavior if the BOS descriptor isn't accessible
and skip all the functionalities that depend on it: LPM support checks,
Super Speed capabilitiy checks, U1/U2 states setup.</Note>
    </Notes>
    <CVE>CVE-2023-52477</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: logitech-hidpp: Fix kernel crash on receiver USB disconnect

hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU)
races when it races with itself.

hidpp_connect_event() primarily runs from a workqueue but it also runs
on probe() and if a "device-connected" packet is received by the hw
when the thread running hidpp_connect_event() from probe() is waiting on
the hw, then a second thread running hidpp_connect_event() will be
started from the workqueue.

This opens the following races (note the below code is simplified):

1. Retrieving + printing the protocol (harmless race):

	if (!hidpp-&gt;protocol_major) {
		hidpp_root_get_protocol_version()
		hidpp-&gt;protocol_major = response.rap.params[0];
	}

We can actually see this race hit in the dmesg in the abrt output
attached to rhbz#2227968:

[ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.
[ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.

Testing with extra logging added has shown that after this the 2 threads
take turn grabbing the hw access mutex (send_mutex) so they ping-pong
through all the other TOCTOU cases managing to hit all of them:

2. Updating the name to the HIDPP name (harmless race):

	if (hidpp-&gt;name == hdev-&gt;name) {
		...
		hidpp-&gt;name = new_name;
	}

3. Initializing the power_supply class for the battery (problematic!):

hidpp_initialize_battery()
{
        if (hidpp-&gt;battery.ps)
                return 0;

	probe_battery(); /* Blocks, threads take turns executing this */

	hidpp-&gt;battery.desc.properties =
		devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);

	hidpp-&gt;battery.ps =
		devm_power_supply_register(&amp;hidpp-&gt;hid_dev-&gt;dev,
					   &amp;hidpp-&gt;battery.desc, cfg);
}

4. Creating delayed input_device (potentially problematic):

	if (hidpp-&gt;delayed_input)
		return;

	hidpp-&gt;delayed_input = hidpp_allocate_input(hdev);

The really big problem here is 3. Hitting the race leads to the following
sequence:

	hidpp-&gt;battery.desc.properties =
		devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);

	hidpp-&gt;battery.ps =
		devm_power_supply_register(&amp;hidpp-&gt;hid_dev-&gt;dev,
					   &amp;hidpp-&gt;battery.desc, cfg);

	...

	hidpp-&gt;battery.desc.properties =
		devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);

	hidpp-&gt;battery.ps =
		devm_power_supply_register(&amp;hidpp-&gt;hid_dev-&gt;dev,
					   &amp;hidpp-&gt;battery.desc, cfg);

So now we have registered 2 power supplies for the same battery,
which looks a bit weird from userspace's pov but this is not even
the really big problem.

Notice how:

1. This is all devm-maganaged
2. The hidpp-&gt;battery.desc struct is shared between the 2 power supplies
3. hidpp-&gt;battery.desc.properties points to the result from the second
   devm_kmemdup()

This causes a use after free scenario on USB disconnect of the receiver:
1. The last registered power supply class device gets unregistered
2. The memory from the last devm_kmemdup() call gets freed,
   hidpp-&gt;battery.desc.properties now points to freed memory
3. The first registered power supply class device gets unregistered,
   this involves sending a remove uevent to userspace which invokes
   power_supply_uevent() to fill the uevent data
4. power_supply_uevent() uses hidpp-&gt;battery.desc.properties which
   now points to freed memory leading to backtraces like this one:

Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08
...
Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event
Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0
...
Sep 22 20:01:35 eric kernel:  ? asm_exc_page_fault+0x26/0x30
Sep 22 20:01:35 eric kernel:  ? power_supply_uevent+0xee/0x1d0
Sep 22 20:01:35 eric kernel:  ? power_supply_uevent+0x10d/0x1d0
Sep 22 20:01:35 eric kernel:  dev_uevent+0x10f/0x2d0
Sep 22 20:01:35 eric kernel:  kobject_uevent_env+0x291/0x680
Sep 22 20:01:35 eric kernel:  
---truncated---</Note>
    </Notes>
    <CVE>CVE-2023-52478</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/srso: Add SRSO mitigation for Hygon processors

Add mitigation for the speculative return stack overflow vulnerability
which exists on Hygon processors too.</Note>
    </Notes>
    <CVE>CVE-2023-52482</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range

When running an SVA case, the following soft lockup is triggered:
--------------------------------------------------------------------
watchdog: BUG: soft lockup - CPU#244 stuck for 26s!
pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50
lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50
sp : ffff8000d83ef290
x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000
x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000
x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0
x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0
x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa
x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a
x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001
Call trace:
 arm_smmu_cmdq_issue_cmdlist+0x178/0xa50
 __arm_smmu_tlb_inv_range+0x118/0x254
 arm_smmu_tlb_inv_range_asid+0x6c/0x130
 arm_smmu_mm_invalidate_range+0xa0/0xa4
 __mmu_notifier_invalidate_range_end+0x88/0x120
 unmap_vmas+0x194/0x1e0
 unmap_region+0xb4/0x144
 do_mas_align_munmap+0x290/0x490
 do_mas_munmap+0xbc/0x124
 __vm_munmap+0xa8/0x19c
 __arm64_sys_munmap+0x28/0x50
 invoke_syscall+0x78/0x11c
 el0_svc_common.constprop.0+0x58/0x1c0
 do_el0_svc+0x34/0x60
 el0_svc+0x2c/0xd4
 el0t_64_sync_handler+0x114/0x140
 el0t_64_sync+0x1a4/0x1a8
--------------------------------------------------------------------

Note that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed
to "arm_smmu_mm_arch_invalidate_secondary_tlbs", yet the problem remains.

The commit 06ff87bae8d3 ("arm64: mm: remove unused functions and variable
protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur
to SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called
typically next to MMU tlb flush function, e.g.
	tlb_flush_mmu_tlbonly {
		tlb_flush {
			__flush_tlb_range {
				// check MAX_TLBI_OPS
			}
		}
		mmu_notifier_arch_invalidate_secondary_tlbs {
			arm_smmu_mm_arch_invalidate_secondary_tlbs {
				// does not check MAX_TLBI_OPS
			}
		}
	}

Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an
SVA case SMMU uses the CPU page table, so it makes sense to align with the
tlbflush code. Then, replace per-page TLBI commands with a single per-asid
TLBI command, if the request size hits this threshold.</Note>
    </Notes>
    <CVE>CVE-2023-52484</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: fix NULL pointer in channel unregistration function

__dma_async_device_channel_register() can fail. In case of failure,
chan-&gt;local is freed (with free_percpu()), and chan-&gt;local is nullified.
When dma_async_device_unregister() is called (because of managed API or
intentionally by DMA controller driver), channels are unconditionally
unregistered, leading to this NULL pointer:
[    1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0
[...]
[    1.484499] Call trace:
[    1.486930]  device_del+0x40/0x394
[    1.490314]  device_unregister+0x20/0x7c
[    1.494220]  __dma_async_device_channel_unregister+0x68/0xc0

Look at dma_async_device_register() function error path, channel device
unregistration is done only if chan-&gt;local is not NULL.

Then add the same condition at the beginning of
__dma_async_device_channel_unregister() function, to avoid NULL pointer
issue whatever the API used to reach this function.</Note>
    </Notes>
    <CVE>CVE-2023-52492</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

erofs: fix lz4 inplace decompression

Currently EROFS can map another compressed buffer for inplace
decompression, that was used to handle the cases that some pages of
compressed data are actually not in-place I/O.

However, like most simple LZ77 algorithms, LZ4 expects the compressed
data is arranged at the end of the decompressed buffer and it
explicitly uses memmove() to handle overlapping:
  __________________________________________________________
 |_ direction of decompression --&gt; ____ |_ compressed data _|

Although EROFS arranges compressed data like this, it typically maps two
individual virtual buffers so the relative order is uncertain.
Previously, it was hardly observed since LZ4 only uses memmove() for
short overlapped literals and x86/arm64 memmove implementations seem to
completely cover it up and they don't have this issue.  Juhyung reported
that EROFS data corruption can be found on a new Intel x86 processor.
After some analysis, it seems that recent x86 processors with the new
FSRM feature expose this issue with "rep movsb".

Let's strictly use the decompressed buffer for lz4 inplace
decompression for now.  Later, as an useful improvement, we could try
to tie up these two buffers together in the correct order.</Note>
    </Notes>
    <CVE>CVE-2023-52497</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ring-buffer: Do not attempt to read past "commit"

When iterating over the ring buffer while the ring buffer is active, the
writer can corrupt the reader. There's barriers to help detect this and
handle it, but that code missed the case where the last event was at the
very end of the page and has only 4 bytes left.

The checks to detect the corruption by the writer to reads needs to see the
length of the event. If the length in the first 4 bytes is zero then the
length is stored in the second 4 bytes. But if the writer is in the process
of updating that code, there's a small window where the length in the first
4 bytes could be zero even though the length is only 4 bytes. That will
cause rb_event_length() to read the next 4 bytes which could happen to be off the
allocated page.

To protect against this, fail immediately if the next event pointer is
less than 8 bytes from the end of the commit (last byte of data), as all
events must be a minimum of 8 bytes anyway.</Note>
    </Notes>
    <CVE>CVE-2023-52501</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()

Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.

Getting a reference on the socket found in a lookup while
holding a lock should happen before releasing the lock.

nfc_llcp_sock_get_sn() has a similar problem.

Finally nfc_llcp_recv_snl() needs to make sure the socket
found by nfc_llcp_sock_from_sn() does not disappear.</Note>
    </Notes>
    <CVE>CVE-2023-52502</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/alternatives: Disable KASAN in apply_alternatives()

Fei has reported that KASAN triggers during apply_alternatives() on
a 5-level paging machine:

	BUG: KASAN: out-of-bounds in rcu_is_watching()
	Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0
	...
	__asan_load4()
	rcu_is_watching()
	trace_hardirqs_on()
	text_poke_early()
	apply_alternatives()
	...

On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57)
gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on
__VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().

KASAN gets confused when apply_alternatives() patches the
KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START
static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.

Fix it for real by disabling KASAN while the kernel is patching alternatives.

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

nfc: nci: assert requested protocol is valid

The protocol is used in a bit mask to determine if the protocol is
supported. Assert the provided protocol is less than the maximum
defined so it doesn't potentially perform a shift-out-of-bounds and
provide a clearer error for undefined protocols vs unsupported ones.</Note>
    </Notes>
    <CVE>CVE-2023-52507</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Prevent null pointer dereference in nvme_fc_io_getuuid()

The nvme_fc_fcp_op structure describing an AEN operation is initialized with a
null request structure pointer. An FC LLDD may make a call to
nvme_fc_io_getuuid passing a pointer to an nvmefc_fcp_req for an AEN operation.

Add validation of the request structure pointer before dereference.</Note>
    </Notes>
    <CVE>CVE-2023-52508</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ieee802154: ca8210: Fix a potential UAF in ca8210_probe

If of_clk_add_provider() fails in ca8210_register_ext_clock(),
it calls clk_unregister() to release priv-&gt;clk and returns an
error. However, the caller ca8210_probe() then calls ca8210_remove(),
where priv-&gt;clk is freed again in ca8210_unregister_ext_clock(). In
this case, a use-after-free may happen in the second time we call
clk_unregister().

Fix this by removing the first clk_unregister(). Also, priv-&gt;clk could
be an error code on failure of clk_register_fixed_rate(). Use
IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().</Note>
    </Notes>
    <CVE>CVE-2023-52510</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sun6i: reduce DMA RX transfer width to single byte

Through empirical testing it has been determined that sometimes RX SPI
transfers with DMA enabled return corrupted data. This is down to single
or even multiple bytes lost during DMA transfer from SPI peripheral to
memory. It seems the RX FIFO within the SPI peripheral can become
confused when performing bus read accesses wider than a single byte to it
during an active SPI transfer.

This patch reduces the width of individual DMA read accesses to the
RX FIFO to a single byte to mitigate that issue.</Note>
    </Notes>
    <CVE>CVE-2023-52511</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/siw: Fix connection failure handling

In case immediate MPA request processing fails, the newly
created endpoint unlinks the listening endpoint and is
ready to be dropped. This special case was not handled
correctly by the code handling the later TCP socket close,
causing a NULL dereference crash in siw_cm_work_handler()
when dereferencing a NULL listener. We now also cancel
the useless MPA timeout, if immediate MPA request
processing fails.

This patch furthermore simplifies MPA processing in general:
Scheduling a useless TCP socket read in sk_data_ready() upcall
is now surpressed, if the socket is already moved out of
TCP_ESTABLISHED state.</Note>
    </Notes>
    <CVE>CVE-2023-52513</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/srp: Do not call scsi_done() from srp_abort()

After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler
callback, it performs one of the following actions:
* Call scsi_queue_insert().
* Call scsi_finish_command().
* Call scsi_eh_scmd_add().
Hence, SCSI abort handlers must not call scsi_done(). Otherwise all
the above actions would trigger a use-after-free. Hence remove the
scsi_done() call from srp_abort(). Keep the srp_free_req() call
before returning SUCCESS because we may not see the command again if
SUCCESS is returned.</Note>
    </Notes>
    <CVE>CVE-2023-52515</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sun6i: fix race between DMA RX transfer completion and RX FIFO drain

Previously the transfer complete IRQ immediately drained to RX FIFO to
read any data remaining in FIFO to the RX buffer. This behaviour is
correct when dealing with SPI in interrupt mode. However in DMA mode the
transfer complete interrupt still fires as soon as all bytes to be
transferred have been stored in the FIFO. At that point data in the FIFO
still needs to be picked up by the DMA engine. Thus the drain procedure
and DMA engine end up racing to read from RX FIFO, corrupting any data
read. Additionally the RX buffer pointer is never adjusted according to
DMA progress in DMA mode, thus calling the RX FIFO drain procedure in DMA
mode is a bug.
Fix corruptions in DMA RX mode by draining RX FIFO only in interrupt mode.
Also wait for completion of RX DMA when in DMA mode before returning to
ensure all data has been copied to the supplied memory buffer.</Note>
    </Notes>
    <CVE>CVE-2023-52517</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit

The EHL (Elkhart Lake) based platforms provide a OOB (Out of band)
service, which allows to wakup device when the system is in S5 (Soft-Off
state). This OOB service can be enabled/disabled from BIOS settings. When
enabled, the ISH device gets PME wake capability. To enable PME wakeup,
driver also needs to enable ACPI GPE bit.

On resume, BIOS will clear the wakeup bit. So driver need to re-enable it
in resume function to keep the next wakeup capability. But this BIOS
clearing of wakeup bit doesn't decrement internal OS GPE reference count,
so this reenabling on every resume will cause reference count to overflow.

So first disable and reenable ACPI GPE bit using acpi_disable_gpe().</Note>
    </Notes>
    <CVE>CVE-2023-52519</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

platform/x86: think-lmi: Fix reference leak

If a duplicate attribute is found using kset_find_obj(), a reference
to that attribute is returned which needs to be disposed accordingly
using kobject_put(). Move the setting name validation into a separate
function to allow for this change without having to duplicate the
cleanup code for this setting.
As a side note, a very similar bug was fixed in
commit 7295a996fdab ("platform/x86: dell-sysman: Fix reference leak"),
so it seems that the bug was copied from that driver.

Compile-tested only.</Note>
    </Notes>
    <CVE>CVE-2023-52520</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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, sockmap: Reject sk_msg egress redirects to non-TCP sockets

With a SOCKMAP/SOCKHASH map and an sk_msg program user can steer messages
sent from one TCP socket (s1) to actually egress from another TCP
socket (s2):

tcp_bpf_sendmsg(s1)		// = sk_prot-&gt;sendmsg
  tcp_bpf_send_verdict(s1)	// __SK_REDIRECT case
    tcp_bpf_sendmsg_redir(s2)
      tcp_bpf_push_locked(s2)
	tcp_bpf_push(s2)
	  tcp_rate_check_app_limited(s2) // expects tcp_sock
	  tcp_sendmsg_locked(s2)	 // ditto

There is a hard-coded assumption in the call-chain, that the egress
socket (s2) is a TCP socket.

However in commit 122e6c79efe1 ("sock_map: Update sock type checks for
UDP") we have enabled redirects to non-TCP sockets. This was done for the
sake of BPF sk_skb programs. There was no indention to support sk_msg
send-to-egress use case.

As a result, attempts to send-to-egress through a non-TCP socket lead to a
crash due to invalid downcast from sock to tcp_sock:

 BUG: kernel NULL pointer dereference, address: 000000000000002f
 ...
 Call Trace:
  &lt;TASK&gt;
  ? show_regs+0x60/0x70
  ? __die+0x1f/0x70
  ? page_fault_oops+0x80/0x160
  ? do_user_addr_fault+0x2d7/0x800
  ? rcu_is_watching+0x11/0x50
  ? exc_page_fault+0x70/0x1c0
  ? asm_exc_page_fault+0x27/0x30
  ? tcp_tso_segs+0x14/0xa0
  tcp_write_xmit+0x67/0xce0
  __tcp_push_pending_frames+0x32/0xf0
  tcp_push+0x107/0x140
  tcp_sendmsg_locked+0x99f/0xbb0
  tcp_bpf_push+0x19d/0x3a0
  tcp_bpf_sendmsg_redir+0x55/0xd0
  tcp_bpf_send_verdict+0x407/0x550
  tcp_bpf_sendmsg+0x1a1/0x390
  inet_sendmsg+0x6a/0x70
  sock_sendmsg+0x9d/0xc0
  ? sockfd_lookup_light+0x12/0x80
  __sys_sendto+0x10e/0x160
  ? syscall_enter_from_user_mode+0x20/0x60
  ? __this_cpu_preempt_check+0x13/0x20
  ? lockdep_hardirqs_on+0x82/0x110
  __x64_sys_sendto+0x1f/0x30
  do_syscall_64+0x38/0x90
  entry_SYSCALL_64_after_hwframe+0x63/0xcd

Reject selecting a non-TCP sockets as redirect target from a BPF sk_msg
program to prevent the crash. When attempted, user will receive an EACCES
error from send/sendto/sendmsg() syscall.</Note>
    </Notes>
    <CVE>CVE-2023-52523</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: nfc: llcp: Add lock when modifying device list

The device list needs its associated lock held when modifying it, or the
list could become corrupted, as syzbot discovered.</Note>
    </Notes>
    <CVE>CVE-2023-52524</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet

Only skip the code path trying to access the rfc1042 headers when the
buffer is too small, so the driver can still process packets without
rfc1042 headers.</Note>
    </Notes>
    <CVE>CVE-2023-52525</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: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg

syzbot reported the following uninit-value access issue:

=====================================================
BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x21c/0x280 lib/dump_stack.c:118
 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121
 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
 smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
 usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737
 usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374
 really_probe+0xf20/0x20b0 drivers/base/dd.c:529
 driver_probe_device+0x293/0x390 drivers/base/dd.c:701
 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
 usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032
 usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241
 usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272
 really_probe+0xf20/0x20b0 drivers/base/dd.c:529
 driver_probe_device+0x293/0x390 drivers/base/dd.c:701
 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
 usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554
 hub_port_connect drivers/usb/core/hub.c:5208 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
 port_event drivers/usb/core/hub.c:5494 [inline]
 hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576
 process_one_work+0x1688/0x2140 kernel/workqueue.c:2269
 worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415
 kthread+0x551/0x590 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293

Local variable ----buf.i87@smsc75xx_bind created at:
 __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
 smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
 __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
 smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482

This issue is caused because usbnet_read_cmd() reads less bytes than requested
(zero byte in the reproducer). In this case, 'buf' is not properly filled.

This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads
less bytes than requested.</Note>
    </Notes>
    <CVE>CVE-2023-52528</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

HID: sony: Fix a potential memory leak in sony_probe()

If an error occurs after a successful usb_alloc_urb() call, usb_free_urb()
should be called.</Note>
    </Notes>
    <CVE>CVE-2023-52529</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: fix potential key use-after-free

When ieee80211_key_link() is called by ieee80211_gtk_rekey_add()
but returns 0 due to KRACK protection (identical key reinstall),
ieee80211_gtk_rekey_add() will still return a pointer into the
key, in a potential use-after-free. This normally doesn't happen
since it's only called by iwlwifi in case of WoWLAN rekey offload
which has its own KRACK protection, but still better to fix, do
that by returning an error code and converting that to success on
the cfg80211 boundary only, leaving the error for bad callers of
ieee80211_gtk_rekey_add().</Note>
    </Notes>
    <CVE>CVE-2023-52530</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: Fix a memory corruption issue

A few lines above, space is kzalloc()'ed for:
	sizeof(struct iwl_nvm_data) +
	sizeof(struct ieee80211_channel) +
	sizeof(struct ieee80211_rate)

'mvm-&gt;nvm_data' is a 'struct iwl_nvm_data', so it is fine.

At the end of this structure, there is the 'channels' flex array.
Each element is of type 'struct ieee80211_channel'.
So only 1 element is allocated in this array.

When doing:
  mvm-&gt;nvm_data-&gt;bands[0].channels = mvm-&gt;nvm_data-&gt;channels;
We point at the first element of the 'channels' flex array.
So this is fine.

However, when doing:
  mvm-&gt;nvm_data-&gt;bands[0].bitrates =
			(void *)((u8 *)mvm-&gt;nvm_data-&gt;channels + 1);
because of the "(u8 *)" cast, we add only 1 to the address of the beginning
of the flex array.

It is likely that we want point at the 'struct ieee80211_rate' allocated
just after.

Remove the spurious casting so that the pointer arithmetic works as
expected.</Note>
    </Notes>
    <CVE>CVE-2023-52531</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 TX CQE error handling

For an unknown TX CQE error type (probably from a newer hardware),
still free the SKB, update the queue tail, etc., otherwise the
accounting will be wrong.

Also, TX errors can be triggered by injecting corrupted packets, so
replace the WARN_ONCE to ratelimited error logging.</Note>
    </Notes>
    <CVE>CVE-2023-52532</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Avoid memory allocation in iommu_suspend()

The iommu_suspend() syscore suspend callback is invoked with IRQ disabled.
Allocating memory with the GFP_KERNEL flag may re-enable IRQs during
the suspend callback, which can cause intermittent suspend/hibernation
problems with the following kernel traces:

Calling iommu_suspend+0x0/0x1d0
------------[ cut here ]------------
WARNING: CPU: 0 PID: 15 at kernel/time/timekeeping.c:868 ktime_get+0x9b/0xb0
...
CPU: 0 PID: 15 Comm: rcu_preempt Tainted: G     U      E      6.3-intel #r1
RIP: 0010:ktime_get+0x9b/0xb0
...
Call Trace:
 &lt;IRQ&gt;
 tick_sched_timer+0x22/0x90
 ? __pfx_tick_sched_timer+0x10/0x10
 __hrtimer_run_queues+0x111/0x2b0
 hrtimer_interrupt+0xfa/0x230
 __sysvec_apic_timer_interrupt+0x63/0x140
 sysvec_apic_timer_interrupt+0x7b/0xa0
 &lt;/IRQ&gt;
 &lt;TASK&gt;
 asm_sysvec_apic_timer_interrupt+0x1f/0x30
...
------------[ cut here ]------------
Interrupts enabled after iommu_suspend+0x0/0x1d0
WARNING: CPU: 0 PID: 27420 at drivers/base/syscore.c:68 syscore_suspend+0x147/0x270
CPU: 0 PID: 27420 Comm: rtcwake Tainted: G     U  W   E      6.3-intel #r1
RIP: 0010:syscore_suspend+0x147/0x270
...
Call Trace:
 &lt;TASK&gt;
 hibernation_snapshot+0x25b/0x670
 hibernate+0xcd/0x390
 state_store+0xcf/0xe0
 kobj_attr_store+0x13/0x30
 sysfs_kf_write+0x3f/0x50
 kernfs_fop_write_iter+0x128/0x200
 vfs_write+0x1fd/0x3c0
 ksys_write+0x6f/0xf0
 __x64_sys_write+0x1d/0x30
 do_syscall_64+0x3b/0x90
 entry_SYSCALL_64_after_hwframe+0x72/0xdc

Given that only 4 words memory is needed, avoid the memory allocation in
iommu_suspend().</Note>
    </Notes>
    <CVE>CVE-2023-52559</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 "tty: n_gsm: fix UAF in gsm_cleanup_mux"

This reverts commit 9b9c8195f3f0d74a826077fc1c01b9ee74907239.

The commit above is reverted as it did not solve the original issue.

gsm_cleanup_mux() tries to free up the virtual ttys by calling
gsm_dlci_release() for each available DLCI. There, dlci_put() is called to
decrease the reference counter for the DLCI via tty_port_put() which
finally calls gsm_dlci_free(). This already clears the pointer which is
being checked in gsm_cleanup_mux() before calling gsm_dlci_release().
Therefore, it is not necessary to clear this pointer in gsm_cleanup_mux()
as done in the reverted commit. The commit introduces a null pointer
dereference:
 &lt;TASK&gt;
 ? __die+0x1f/0x70
 ? page_fault_oops+0x156/0x420
 ? search_exception_tables+0x37/0x50
 ? fixup_exception+0x21/0x310
 ? exc_page_fault+0x69/0x150
 ? asm_exc_page_fault+0x26/0x30
 ? tty_port_put+0x19/0xa0
 gsmtty_cleanup+0x29/0x80 [n_gsm]
 release_one_tty+0x37/0xe0
 process_one_work+0x1e6/0x3e0
 worker_thread+0x4c/0x3d0
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe1/0x110
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2f/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
 &lt;/TASK&gt;

The actual issue is that nothing guards dlci_put() from being called
multiple times while the tty driver was triggered but did not yet finished
calling gsm_dlci_free().</Note>
    </Notes>
    <CVE>CVE-2023-52564</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 potential use after free in nilfs_gccache_submit_read_data()

In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the
reference count of bh when the call to nilfs_dat_translate() fails.  If
the reference count hits 0 and its owner page gets unlocked, bh may be
freed.  However, bh-&gt;b_page is dereferenced to put the page after that,
which may result in a use-after-free bug.  This patch moves the release
operation after unlocking and putting the page.

NOTE: The function in question is only called in GC, and in combination
with current userland tools, address translation using DAT does not occur
in that function, so the code path that causes this issue will not be
executed.  However, it is possible to run that code path by intentionally
modifying the userland GC library or by calling the GC ioctl directly.

[konishi.ryusuke@gmail.com: NOTE added to the commit log]</Note>
    </Notes>
    <CVE>CVE-2023-52566</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: 8250_port: Check IRQ data before use

In case the leaf driver wants to use IRQ polling (irq = 0) and
IIR register shows that an interrupt happened in the 8250 hardware
the IRQ data can be NULL. In such a case we need to skip the wake
event as we came to this path from the timer interrupt and quite
likely system is already awake.

Without this fix we have got an Oops:

    serial8250: ttyS0 at I/O 0x3f8 (irq = 0, base_baud = 115200) is a 16550A
    ...
    BUG: kernel NULL pointer dereference, address: 0000000000000010
    RIP: 0010:serial8250_handle_irq+0x7c/0x240
    Call Trace:
     ? serial8250_handle_irq+0x7c/0x240
     ? __pfx_serial8250_timeout+0x10/0x10</Note>
    </Notes>
    <CVE>CVE-2023-52567</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: remove BUG() after failure to insert delayed dir index item

Instead of calling BUG() when we fail to insert a delayed dir index item
into the delayed node's tree, we can just release all the resources we
have allocated/acquired before and return the error to the caller. This is
fine because all existing call chains undo anything they have done before
calling btrfs_insert_delayed_dir_index() or BUG_ON (when creating pending
snapshots in the transaction commit path).

So remove the BUG() call and do proper error handling.

This relates to a syzbot report linked below, but does not fix it because
it only prevents hitting a BUG(), it does not fix the issue where somehow
we attempt to use twice the same index number for different index items.</Note>
    </Notes>
    <CVE>CVE-2023-52569</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

team: fix null-ptr-deref when team device type is changed

Get a null-ptr-deref bug as follows with reproducer [1].

BUG: kernel NULL pointer dereference, address: 0000000000000228
...
RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q]
...
Call Trace:
 &lt;TASK&gt;
 ? __die+0x24/0x70
 ? page_fault_oops+0x82/0x150
 ? exc_page_fault+0x69/0x150
 ? asm_exc_page_fault+0x26/0x30
 ? vlan_dev_hard_header+0x35/0x140 [8021q]
 ? vlan_dev_hard_header+0x8e/0x140 [8021q]
 neigh_connected_output+0xb2/0x100
 ip6_finish_output2+0x1cb/0x520
 ? nf_hook_slow+0x43/0xc0
 ? ip6_mtu+0x46/0x80
 ip6_finish_output+0x2a/0xb0
 mld_sendpack+0x18f/0x250
 mld_ifc_work+0x39/0x160
 process_one_work+0x1e6/0x3f0
 worker_thread+0x4d/0x2f0
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe5/0x120
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x34/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30

[1]
$ teamd -t team0 -d -c '{"runner": {"name": "loadbalance"}}'
$ ip link add name t-dummy type dummy
$ ip link add link t-dummy name t-dummy.100 type vlan id 100
$ ip link add name t-nlmon type nlmon
$ ip link set t-nlmon master team0
$ ip link set t-nlmon nomaster
$ ip link set t-dummy up
$ ip link set team0 up
$ ip link set t-dummy.100 down
$ ip link set t-dummy.100 master team0

When enslave a vlan device to team device and team device type is changed
from non-ether to ether, header_ops of team device is changed to
vlan_header_ops. That is incorrect and will trigger null-ptr-deref
for vlan-&gt;real_dev in vlan_dev_hard_header() because team device is not
a vlan device.

Cache eth_header_ops in team_setup(), then assign cached header_ops to
header_ops of team net device when its type is changed from non-ether
to ether to fix the bug.</Note>
    </Notes>
    <CVE>CVE-2023-52574</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">** REJECT ** This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.</Note>
    </Notes>
    <CVE>CVE-2023-52575</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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, kexec, ima: Use memblock_free_late() from ima_free_kexec_buffer()

The code calling ima_free_kexec_buffer() runs long after the memblock
allocator has already been torn down, potentially resulting in a use
after free in memblock_isolate_range().

With KASAN or KFENCE, this use after free will result in a BUG
from the idle task, and a subsequent kernel panic.

Switch ima_free_kexec_buffer() over to memblock_free_late() to avoid
that bug.</Note>
    </Notes>
    <CVE>CVE-2023-52576</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

netfs: Only call folio_start_fscache() one time for each folio

If a network filesystem using netfs implements a clamp_length()
function, it can set subrequest lengths smaller than a page size.

When we loop through the folios in netfs_rreq_unlock_folios() to
set any folios to be written back, we need to make sure we only
call folio_start_fscache() once for each folio.

Otherwise, this simple testcase:

  mount -o fsc,rsize=1024,wsize=1024 127.0.0.1:/export /mnt/nfs
  dd if=/dev/zero of=/mnt/nfs/file.bin bs=4096 count=1
  1+0 records in
  1+0 records out
  4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0126359 s, 324 kB/s
  echo 3 &gt; /proc/sys/vm/drop_caches
  cat /mnt/nfs/file.bin &gt; /dev/null

will trigger an oops similar to the following:

  page dumped because: VM_BUG_ON_FOLIO(folio_test_private_2(folio))
  ------------[ cut here ]------------
  kernel BUG at include/linux/netfs.h:44!
  ...
  CPU: 5 PID: 134 Comm: kworker/u16:5 Kdump: loaded Not tainted 6.4.0-rc5
  ...
  RIP: 0010:netfs_rreq_unlock_folios+0x68e/0x730 [netfs]
  ...
  Call Trace:
    netfs_rreq_assess+0x497/0x660 [netfs]
    netfs_subreq_terminated+0x32b/0x610 [netfs]
    nfs_netfs_read_completion+0x14e/0x1a0 [nfs]
    nfs_read_completion+0x2f9/0x330 [nfs]
    rpc_free_task+0x72/0xa0 [sunrpc]
    rpc_async_release+0x46/0x70 [sunrpc]
    process_one_work+0x3bd/0x710
    worker_thread+0x89/0x610
    kthread+0x181/0x1c0
    ret_from_fork+0x29/0x50</Note>
    </Notes>
    <CVE>CVE-2023-52582</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ceph: fix deadlock or deadcode of misusing dget()

The lock order is incorrect between denty and its parent, we should
always make sure that the parent get the lock first.

But since this deadcode is never used and the parent dir will always
be set from the callers, let's just remove it.</Note>
    </Notes>
    <CVE>CVE-2023-52583</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

reiserfs: Avoid touching renamed directory if parent does not change

The VFS will not be locking moved directory if its parent does not
change. Change reiserfs rename code to avoid touching renamed directory
if its parent does not change as without locking that can corrupt the
filesystem.</Note>
    </Notes>
    <CVE>CVE-2023-52591</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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: s390: fix setting of fpc register

kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control
(fpc) register of a guest cpu. The new value is tested for validity by
temporarily loading it into the fpc register.

This may lead to corruption of the fpc register of the host process:
if an interrupt happens while the value is temporarily loaded into the fpc
register, and within interrupt context floating point or vector registers
are used, the current fp/vx registers are saved with save_fpu_regs()
assuming they belong to user space and will be loaded into fp/vx registers
when returning to user space.

test_fp_ctl() restores the original user space / host process fpc register
value, however it will be discarded, when returning to user space.

In result the host process will incorrectly continue to run with the value
that was supposed to be used for a guest cpu.

Fix this by simply removing the test. There is another test right before
the SIE context is entered which will handles invalid values.

This results in a change of behaviour: invalid values will now be accepted
instead of that the ioctl fails with -EINVAL. This seems to be acceptable,
given that this interface is most likely not used anymore, and this is in
addition the same behaviour implemented with the memory mapped interface
(replace invalid values with zero) - see sync_regs() in kvm-s390.c.</Note>
    </Notes>
    <CVE>CVE-2023-52597</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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-52605</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

powerpc/mm: Fix null-pointer dereference in pgtable_cache_add

kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.</Note>
    </Notes>
    <CVE>CVE-2023-52607</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init

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

usb: aqc111: check packet for fixup for true limit

If a device sends a packet that is inbetween 0
and sizeof(u64) the value passed to skb_trim()
as length will wrap around ending up as some very
large value.

The driver will then proceed to parse the header
located at that position, which will either oops or
process some random value.

The fix is to check against sizeof(u64) rather than
0, which the driver currently does. The issue exists
since the introduction of the driver.</Note>
    </Notes>
    <CVE>CVE-2023-52655</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

rpmsg: virtio: Free driver_override when rpmsg_remove()

Free driver_override when rpmsg_remove(), otherwise
the following memory leak will occur:

unreferenced object 0xffff0000d55d7080 (size 128):
  comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s)
  hex dump (first 32 bytes):
    72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00  rpmsg_ns........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;000000009c94c9c1&gt;] __kmem_cache_alloc_node+0x1f8/0x320
    [&lt;000000002300d89b&gt;] __kmalloc_node_track_caller+0x44/0x70
    [&lt;00000000228a60c3&gt;] kstrndup+0x4c/0x90
    [&lt;0000000077158695&gt;] driver_set_override+0xd0/0x164
    [&lt;000000003e9c4ea5&gt;] rpmsg_register_device_override+0x98/0x170
    [&lt;000000001c0c89a8&gt;] rpmsg_ns_register_device+0x24/0x30
    [&lt;000000008bbf8fa2&gt;] rpmsg_probe+0x2e0/0x3ec
    [&lt;00000000e65a68df&gt;] virtio_dev_probe+0x1c0/0x280
    [&lt;00000000443331cc&gt;] really_probe+0xbc/0x2dc
    [&lt;00000000391064b1&gt;] __driver_probe_device+0x78/0xe0
    [&lt;00000000a41c9a5b&gt;] driver_probe_device+0xd8/0x160
    [&lt;000000009c3bd5df&gt;] __device_attach_driver+0xb8/0x140
    [&lt;0000000043cd7614&gt;] bus_for_each_drv+0x7c/0xd4
    [&lt;000000003b929a36&gt;] __device_attach+0x9c/0x19c
    [&lt;00000000a94e0ba8&gt;] device_initial_probe+0x14/0x20
    [&lt;000000003c999637&gt;] bus_probe_device+0xa0/0xac</Note>
    </Notes>
    <CVE>CVE-2023-52670</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Guard stack limits against 32bit overflow

This patch promotes the arithmetic around checking stack bounds to be
done in the 64-bit domain, instead of the current 32bit. The arithmetic
implies adding together a 64-bit register with a int offset. The
register was checked to be below 1&lt;&lt;29 when it was variable, but not
when it was fixed. The offset either comes from an instruction (in which
case it is 16 bit), from another register (in which case the caller
checked it to be below 1&lt;&lt;29 [1]), or from the size of an argument to a
kfunc (in which case it can be a u32 [2]). Between the register being
inconsistently checked to be below 1&lt;&lt;29, and the offset being up to an
u32, it appears that we were open to overflowing the `int`s which were
currently used for arithmetic.

[1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498
[2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904</Note>
    </Notes>
    <CVE>CVE-2023-52676</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:

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:

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:

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:

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:

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:

smb: client: fix use-after-free bug in cifs_debug_data_proc_show()

Skip SMB sessions that are being teared down
(e.g. @ses-&gt;ses_status == SES_EXITING) in cifs_debug_data_proc_show()
to avoid use-after-free in @ses.

This fixes the following GPF when reading from /proc/fs/cifs/DebugData
while mounting and umounting

  [ 816.251274] general protection fault, probably for non-canonical
  address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI
  ...
  [  816.260138] Call Trace:
  [  816.260329]  &lt;TASK&gt;
  [  816.260499]  ? die_addr+0x36/0x90
  [  816.260762]  ? exc_general_protection+0x1b3/0x410
  [  816.261126]  ? asm_exc_general_protection+0x26/0x30
  [  816.261502]  ? cifs_debug_tcon+0xbd/0x240 [cifs]
  [  816.261878]  ? cifs_debug_tcon+0xab/0x240 [cifs]
  [  816.262249]  cifs_debug_data_proc_show+0x516/0xdb0 [cifs]
  [  816.262689]  ? seq_read_iter+0x379/0x470
  [  816.262995]  seq_read_iter+0x118/0x470
  [  816.263291]  proc_reg_read_iter+0x53/0x90
  [  816.263596]  ? srso_alias_return_thunk+0x5/0x7f
  [  816.263945]  vfs_read+0x201/0x350
  [  816.264211]  ksys_read+0x75/0x100
  [  816.264472]  do_syscall_64+0x3f/0x90
  [  816.264750]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
  [  816.265135] RIP: 0033:0x7fd5e669d381</Note>
    </Notes>
    <CVE>CVE-2023-52752</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Avoid NULL dereference of timing generator

[Why &amp; How]
Check whether assigned timing generator is NULL or not before
accessing its funcs to prevent NULL dereference.</Note>
    </Notes>
    <CVE>CVE-2023-52753</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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">** 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:

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:

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:

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:

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:

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

nbd: fix uaf in nbd_open

Commit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk and
blk_cleanup_disk") cleans up disk by blk_cleanup_disk() and it won't set
disk-&gt;private_data as NULL as before. UAF may be triggered in nbd_open()
if someone tries to open nbd device right after nbd_put() since nbd has
been free in nbd_dev_remove().

Fix this by implementing -&gt;free_disk and free private data in it.</Note>
    </Notes>
    <CVE>CVE-2023-52837</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

hsr: Prevent use after free in prp_create_tagged_frame()

The prp_fill_rct() function can fail.  In that situation, it frees the
skb and returns NULL.  Meanwhile on the success path, it returns the
original skb.  So it's straight forward to fix bug by using the returned
value.</Note>
    </Notes>
    <CVE>CVE-2023-52846</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

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:

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">In the Linux kernel, the following vulnerability has been resolved:

tcp: do not accept ACK of bytes we never sent

This patch is based on a detailed report and ideas from Yepeng Pan
and Christian Rossow.

ACK seq validation is currently following RFC 5961 5.2 guidelines:

   The ACK value is considered acceptable only if
   it is in the range of ((SND.UNA - MAX.SND.WND) &lt;= SEG.ACK &lt;=
   SND.NXT).  All incoming segments whose ACK value doesn't satisfy the
   above condition MUST be discarded and an ACK sent back.  It needs to
   be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a
   duplicate (SEG.ACK &lt; SND.UNA), it can be ignored.  If the ACK
   acknowledges something not yet sent (SEG.ACK &gt; SND.NXT) then send an
   ACK, drop the segment, and return".  The "ignored" above implies that
   the processing of the incoming data segment continues, which means
   the ACK value is treated as acceptable.  This mitigation makes the
   ACK check more stringent since any ACK &lt; SND.UNA wouldn't be
   accepted, instead only ACKs that are in the range ((SND.UNA -
   MAX.SND.WND) &lt;= SEG.ACK &lt;= SND.NXT) get through.

This can be refined for new (and possibly spoofed) flows,
by not accepting ACK for bytes that were never sent.

This greatly improves TCP security at a little cost.

I added a Fixes: tag to make sure this patch will reach stable trees,
even if the 'blamed' patch was adhering to the RFC.

tp-&gt;bytes_acked was added in linux-4.2

Following packetdrill test (courtesy of Yepeng Pan) shows
the issue at hand:

0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1024) = 0

// ---------------- Handshake ------------------- //

// when window scale is set to 14 the window size can be extended to
// 65535 * (2^14) = 1073725440. Linux would accept an ACK packet
// with ack number in (Server_ISN+1-1073725440. Server_ISN+1)
// ,though this ack number acknowledges some data never
// sent by the server.

+0 &lt; S 0:0(0) win 65535 &lt;mss 1400,nop,wscale 14&gt;
+0 &gt; S. 0:0(0) ack 1 &lt;...&gt;
+0 &lt; . 1:1(0) ack 1 win 65535
+0 accept(3, ..., ...) = 4

// For the established connection, we send an ACK packet,
// the ack packet uses ack number 1 - 1073725300 + 2^32,
// where 2^32 is used to wrap around.
// Note: we used 1073725300 instead of 1073725440 to avoid possible
// edge cases.
// 1 - 1073725300 + 2^32 = 3221241997

// Oops, old kernels happily accept this packet.
+0 &lt; . 1:1001(1000) ack 3221241997 win 65535

// After the kernel fix the following will be replaced by a challenge ACK,
// and prior malicious frame would be dropped.
+0 &gt; . 1:1(0) ack 1001</Note>
    </Notes>
    <CVE>CVE-2023-52881</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 flaw in query-handling code can cause `named` to exit prematurely with an assertion failure when:

  - `nxdomain-redirect &lt;domain&gt;;` is configured, and
  - the resolver receives a PTR query for an RFC 1918 address that would normally result in an authoritative NXDOMAIN response.
This issue affects BIND 9 versions 9.12.0 through 9.16.45, 9.18.0 through 9.18.21, 9.19.0 through 9.19.19, 9.16.8-S1 through 9.16.45-S1, and 9.18.11-S1 through 9.18.21-S1.</Note>
    </Notes>
    <CVE>CVE-2023-5517</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 bad interaction between DNS64 and serve-stale may cause `named` to crash with an assertion failure during recursive resolution, when both of these features are enabled.
This issue affects BIND 9 versions 9.16.12 through 9.16.45, 9.18.0 through 9.18.21, 9.19.0 through 9.19.19, 9.16.12-S1 through 9.16.45-S1, and 9.18.11-S1 through 9.18.21-S1.</Note>
    </Notes>
    <CVE>CVE-2023-5679</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found that the response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from response times of ciphertexts with correct PKCS#1 v1.5 padding.</Note>
    </Notes>
    <CVE>CVE-2023-5981</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in OpenSC where PKCS#1 encryption padding removal is not implemented as side-channel resistant. This issue may result in the potential leak of private data.</Note>
    </Notes>
    <CVE>CVE-2023-5992</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An out-of-bounds access vulnerability involving netfilter was reported and fixed as: f1082dd31fe4 (netfilter: nf_tables: Reject tables of unsupported family); While creating a new netfilter table, lack of a safeguard against invalid nf_tables family (pf) values within `nf_tables_newtable` function enables an attacker to achieve out-of-bounds access.</Note>
    </Notes>
    <CVE>CVE-2023-6040</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution.</Note>
    </Notes>
    <CVE>CVE-2023-6270</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver and causing kernel panic and a denial of service.</Note>
    </Notes>
    <CVE>CVE-2023-6356</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">To keep its cache database efficient, `named` running as a recursive resolver occasionally attempts to clean up the database. It uses several methods, including some that are asynchronous: a small chunk of memory pointing to the cache element that can be cleaned up is first allocated and then queued for later processing. It was discovered that if the resolver is continuously processing query patterns triggering this type of cache-database maintenance, `named` may not be able to handle the cleanup events in a timely manner. This in turn enables the list of queued cleanup events to grow infinitely large over time, allowing the configured `max-cache-size` limit to be significantly exceeded.
This issue affects BIND 9 versions 9.16.0 through 9.16.45 and 9.16.8-S1 through 9.16.45-S1.</Note>
    </Notes>
    <CVE>CVE-2023-6516</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 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">A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service.</Note>
    </Notes>
    <CVE>CVE-2023-6535</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service.</Note>
    </Notes>
    <CVE>CVE-2023-6536</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was found in the CPython `tempfile.TemporaryDirectory` class affecting versions 3.12.1, 3.11.7, 3.10.13, 3.9.18, and 3.8.18 and prior.

The tempfile.TemporaryDirectory class would dereference symlinks during cleanup of permissions-related errors. This means users which can run privileged programs are potentially able to modify permissions of files referenced by symlinks in some circumstances.
</Note>
    </Notes>
    <CVE>CVE-2023-6597</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.

The function nft_pipapo_walk did not skip inactive elements during set walk which could lead double deactivations of PIPAPO (Pile Packet Policies) elements, leading to use-after-free.

We recommend upgrading past commit 317eb9685095678f2c9f5a8189de698c5354316a.

</Note>
    </Notes>
    <CVE>CVE-2023-6817</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 problem was found in ida_free in lib/idr.c in the Linux Kernel. This issue may allow an attacker using this library to cause a denial of service problem due to a missing check at a function return.</Note>
    </Notes>
    <CVE>CVE-2023-6915</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service.</Note>
    </Notes>
    <CVE>CVE-2023-7042</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A memory leak problem was found in ctnetlink_create_conntrack in net/netfilter/nf_conntrack_netlink.c in the Linux Kernel. This issue may allow a local attacker with CAP_NET_ADMIN privileges to cause a denial of service (DoS) attack due to a refcount overflow.</Note>
    </Notes>
    <CVE>CVE-2023-7192</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not properly initialize memory in messages passed between virtual guests and the host operating system in the vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel memory contents when reading from the /dev/vhost-net device file.</Note>
    </Notes>
    <CVE>CVE-2024-0340</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A defect was discovered in the Python "ssl" module where there is a memory
race condition with the ssl.SSLContext methods "cert_store_stats()" and
"get_ca_certs()". The race condition can be triggered if the methods are
called at the same time as certificates are loaded into the SSLContext,
such as during the TLS handshake with a certificate directory configured.
This issue is fixed in CPython 3.10.14, 3.11.9, 3.12.3, and 3.13.0a5.</Note>
    </Notes>
    <CVE>CVE-2024-0397</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An issue was found in the CPython `zipfile` module affecting versions 3.12.1, 3.11.7, 3.10.13, 3.9.18, and 3.8.18 and prior.

The zipfile module is vulnerable to "quoted-overlap" zip-bombs which exploit the zip format to create a zip-bomb with a high compression ratio. The fixed versions of CPython makes the zipfile module reject zip archives which overlap entries in the archive.

</Note>
    </Notes>
    <CVE>CVE-2024-0450</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in GnuTLS. The response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from the response times of ciphertexts with correct PKCS#1 v1.5 padding. This issue may allow a remote attacker to perform a timing side-channel attack in the RSA-PSK key exchange, potentially leading to the leakage of sensitive data. CVE-2024-0553 is designated as an incomplete resolution for CVE-2023-5981.</Note>
    </Notes>
    <CVE>CVE-2024-0553</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">An out-of-bounds memory read flaw was found in receive_encrypted_standard in fs/smb/client/smb2ops.c in the SMB Client sub-component in the Linux Kernel. This issue occurs due to integer underflow on the memcpy length, leading to a denial of service.</Note>
    </Notes>
    <CVE>CVE-2024-0565</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was found in GnuTLS, where a cockpit (which uses gnuTLS) rejects a certificate chain with distributed trust. This issue occurs when validating a certificate chain with cockpit-certificate-ensure. This flaw allows an unauthenticated, remote client or attacker to initiate a denial of service attack.</Note>
    </Notes>
    <CVE>CVE-2024-0567</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 Netfilter subsystem in the Linux kernel. The issue is in the nft_byteorder_eval() function, where the code iterates through a loop and writes to the `dst` array. On each iteration, 8 bytes are written, but `dst` is an array of u32, so each element only has space for 4 bytes. That means every iteration overwrites part of the previous element corrupting this array of u32. This flaw allows a local user to cause a denial of service or potentially break NetFilter functionality.</Note>
    </Notes>
    <CVE>CVE-2024-0607</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A denial of service vulnerability due to a deadlock was found in sctp_auto_asconf_init in net/sctp/socket.c in the Linux kernel's SCTP subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.</Note>
    </Notes>
    <CVE>CVE-2024-0639</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A denial of service vulnerability was found in tipc_crypto_key_revoke in net/tipc/crypto.c in the Linux kernel's TIPC subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.</Note>
    </Notes>
    <CVE>CVE-2024-0641</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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: Processing a maliciously formatted PKCS12 file may lead OpenSSL
to crash leading to a potential Denial of Service attack

Impact summary: Applications loading files in the PKCS12 format from untrusted
sources might terminate abruptly.

A file in PKCS12 format can contain certificates and keys and may come from an
untrusted source. The PKCS12 specification allows certain fields to be NULL, but
OpenSSL does not correctly check for this case. This can lead to a NULL pointer
dereference that results in OpenSSL crashing. If an application processes PKCS12
files from an untrusted source using the OpenSSL APIs then that application will
be vulnerable to this issue.

OpenSSL APIs that are vulnerable to this are: PKCS12_parse(),
PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()
and PKCS12_newpass().

We have also fixed a similar issue in SMIME_write_PKCS7(). However since this
function is related to writing data we do not consider it security significant.

The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.</Note>
    </Notes>
    <CVE>CVE-2024-0727</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A use-after-free flaw was found in the __ext4_remount in fs/ext4/super.c in ext4 in the Linux kernel. This flaw allows a local user to cause an information leak problem while freeing the old quota file names before a potential failure, leading to a use-after-free.</Note>
    </Notes>
    <CVE>CVE-2024-0775</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A null pointer dereference flaw was found in the hugetlbfs_fill_super function in the Linux kernel hugetlbfs (HugeTLB pages) functionality. This issue may allow a local user to crash the system or potentially escalate their privileges on the system.</Note>
    </Notes>
    <CVE>CVE-2024-0841</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.

The nft_setelem_catchall_deactivate() function checks whether the catch-all set element is active in the current generation instead of the next generation before freeing it, but only flags it inactive in the next generation, making it possible to free the element multiple times, leading to a double free vulnerability.

We recommend upgrading past commit b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7.

</Note>
    </Notes>
    <CVE>CVE-2024-1085</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 use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.

The nft_verdict_init() function allows positive values as drop error within the hook verdict, and hence the nf_hook_slow() function can cause a double free vulnerability when NF_DROP is issued with a drop error which resembles NF_ACCEPT.

We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660.

</Note>
    </Notes>
    <CVE>CVE-2024-1086</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A vulnerability was reported in the Open vSwitch sub-component in the Linux Kernel. The flaw occurs when a recursive operation of code push recursively calls into the code block. The OVS module does not validate the stack depth, pushing too many frames and causing a stack overflow. As a result, this can lead to a crash or other related issues.</Note>
    </Notes>
    <CVE>CVE-2024-1151</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When a protocol selection parameter option disables all protocols without adding any then the default set of protocols would remain in the allowed set due to an error in the logic for removing protocols. The below command would perform a request to curl.se with a plaintext protocol which has been explicitly disabled.      curl --proto -all,-http http://curl.se  The flaw is only present if the set of selected protocols disables the entire set of available protocols, in itself a command with no practical use and therefore unlikely to be encountered in real situations. The curl security team has thus assessed this to be low severity bug.</Note>
    </Notes>
    <CVE>CVE-2024-2004</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">runc is a CLI tool for spawning and running containers on Linux according to the OCI specification. In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from runc exec) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem ("attack 2"). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through runc run ("attack 1"). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes ("attack 3a" and "attack 3b"). runc 1.1.12 includes patches for this issue. </Note>
    </Notes>
    <CVE>CVE-2024-21626</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 Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative executable code paths.</Note>
    </Notes>
    <CVE>CVE-2024-2193</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A cross-privilege Spectre v2 vulnerability allows attackers to bypass all deployed mitigations, including the recent Fine(IBT), and to leak arbitrary Linux kernel memory on Intel systems.</Note>
    </Notes>
    <CVE>CVE-2024-2201</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">NULL Pointer Dereference vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (net, bluetooth modules) allows Overflow Buffers. This vulnerability is associated with program files /net/bluetooth/rfcomm/core.C.

This issue affects Linux kernel: v2.6.12-rc2.

</Note>
    </Notes>
    <CVE>CVE-2024-22099</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Jinja is an extensible templating engine. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template, potentially leading to Cross-Site Scripting (XSS). The Jinja `xmlattr` filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.
</Note>
    </Notes>
    <CVE>CVE-2024-22195</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Syndic cache directory creation is vulnerable to a directory traversal attack in salt project which can lead  a malicious attacker to create an arbitrary directory on a Salt master.</Note>
    </Notes>
    <CVE>CVE-2024-22231</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 specially crafted url can be created which leads to a directory traversal in the salt file server.
A malicious user can read an arbitrary file from a Salt master's filesystem.</Note>
    </Notes>
    <CVE>CVE-2024-22232</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">Vim before 9.0.2142 has a stack-based buffer overflow because did_set_langmap in map.c calls sprintf to write to the error buffer that is passed down to the option callback functions.</Note>
    </Notes>
    <CVE>CVE-2024-22667</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">Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow.</Note>
    </Notes>
    <CVE>CVE-2024-23307</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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">BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Two malicious build steps running in parallel sharing the same cache mounts with subpaths could cause a race condition that can lead to files from the host system being accessible to the build container. The issue has been fixed in v0.12.5. Workarounds include, avoiding using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing cache mounts with --mount=type=cache,source=... options.
</Note>
    </Notes>
    <CVE>CVE-2024-23651</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">BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. A malicious BuildKit frontend or Dockerfile using RUN --mount could trick the feature that removes empty files created for the mountpoints into removing a file outside the container, from the host system. The issue has been fixed in v0.12.5. Workarounds include avoiding using BuildKit frontends from an untrusted source or building an untrusted Dockerfile containing RUN --mount feature.</Note>
    </Notes>
    <CVE>CVE-2024-23652</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. In addition to running containers as build steps, BuildKit also provides APIs for running interactive containers based on built images. It was possible to use these APIs to ask BuildKit to run a container with elevated privileges. Normally, running such containers is only allowed if special `security.insecure` entitlement is enabled both by buildkitd configuration and allowed by the user initializing the build request. The issue has been fixed in v0.12.5 . Avoid using BuildKit frontends from untrusted sources. 
</Note>
    </Notes>
    <CVE>CVE-2024-23653</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel through 6.7.1, there is a use-after-free in cec_queue_msg_fh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c.</Note>
    </Notes>
    <CVE>CVE-2024-23848</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In rds_recv_track_latency in net/rds/af_rds.c in the Linux kernel through 6.7.1, there is an off-by-one error for an RDS_MSG_RX_DGRAM_TRACE_MAX comparison, resulting in out-of-bounds access.</Note>
    </Notes>
    <CVE>CVE-2024-23849</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In btrfs_get_root_ref in fs/btrfs/disk-io.c in the Linux kernel through 6.7.1, there can be an assertion failure and crash because a subvolume can be read out too soon after its root item is inserted upon subvolume creation.</Note>
    </Notes>
    <CVE>CVE-2024-23850</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">When an application tells libcurl it wants to allow HTTP/2 server push, and the amount of received headers for the push surpasses the maximum allowed limit (1000), libcurl aborts the server push. When aborting, libcurl inadvertently does not free all the previously allocated headers and instead leaks the memory.  Further, this error condition fails silently and is therefore not easily detected by an application.</Note>
    </Notes>
    <CVE>CVE-2024-2398</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A race condition was found in the Linux kernel's bluetooth device driver in {min,max}_key_size_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.




</Note>
    </Notes>
    <CVE>CVE-2024-24860</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 RPC library APIs of libvirt. The RPC server deserialization code allocates memory for arrays before the non-negative length check is performed by the C API entry points. Passing a negative length to the g_new0 function results in a crash due to the negative length being treated as a huge positive number. This flaw allows a local, unprivileged user to perform a denial of service attack by causing the libvirt daemon to crash.</Note>
    </Notes>
    <CVE>CVE-2024-2494</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 libxml2 before 2.11.7 and 2.12.x before 2.12.5. When using the XML Reader interface with DTD validation and XInclude expansion enabled, processing crafted XML documents can lead to an xmlValidatePopElement use-after-free.</Note>
    </Notes>
    <CVE>CVE-2024-25062</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">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">Rack is a modular Ruby web server interface. Carefully crafted content type headers can cause Rack's media type parser to take much longer than expected, leading to a possible denial of service vulnerability (ReDos 2nd degree polynomial). This vulnerability is patched in 3.0.9.1 and 2.2.8.1.</Note>
    </Notes>
    <CVE>CVE-2024-25126</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">c-ares is a C library for asynchronous DNS requests. `ares__read_line()` is used to parse local configuration files such as `/etc/resolv.conf`, `/etc/nsswitch.conf`, the `HOSTALIASES` file, and if using a c-ares version prior to 1.27.0, the `/etc/hosts` file. If any of these configuration files has an embedded `NULL` character as the first character in a new line, it can lead to attempting to read memory prior to the start of the given buffer which may result in a crash. This issue is fixed in c-ares 1.27.0. No known workarounds exist.</Note>
    </Notes>
    <CVE>CVE-2024-25629</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel before 6.9, an untrusted hypervisor can inject virtual interrupt 29 (#VC) at any point in time and can trigger its handler. This affects AMD SEV-SNP and AMD SEV-ES.</Note>
    </Notes>
    <CVE>CVE-2024-25742</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Rack is a modular Ruby web server interface. Carefully crafted Range headers can cause a server to respond with an unexpectedly large response. Responding with such large responses could lead to a denial of service issue. Vulnerable applications will use the `Rack::File` middleware or the `Rack::Utils.byte_ranges` methods (this includes Rails applications). The vulnerability is fixed in 3.0.9.1 and 2.2.8.1.</Note>
    </Notes>
    <CVE>CVE-2024-26141</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Rack is a modular Ruby web server interface. Carefully crafted headers can cause header parsing in Rack to take longer than expected resulting in a possible denial of service issue. Accept and Forwarded headers are impacted. Ruby 3.2 has mitigations for this problem, so Rack applications using Ruby 3.2 or newer are unaffected. This vulnerability is fixed in 2.0.9.4, 2.1.4.4, 2.2.8.1, and 3.0.9.1.
</Note>
    </Notes>
    <CVE>CVE-2024-26146</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">Kerberos 5 (aka krb5) 1.21.2 contains a memory leak in /krb5/src/lib/rpc/pmap_rmt.c.</Note>
    </Notes>
    <CVE>CVE-2024-26458</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">Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/lib/gssapi/krb5/k5sealv3.c.</Note>
    </Notes>
    <CVE>CVE-2024-26461</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tls: fix race between tx work scheduling and socket close

Similarly to previous commit, the submitting thread (recvmsg/sendmsg)
may exit as soon as the async crypto handler calls complete().
Reorder scheduling the work before calling complete().
This seems more logical in the first place, as it's
the inverse order of what the submitting thread will do.</Note>
    </Notes>
    <CVE>CVE-2024-26585</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 stack corruption

When tc filters are first added to a net device, the corresponding local
port gets bound to an ACL group in the device. The group contains a list
of ACLs. In turn, each ACL points to a different TCAM region where the
filters are stored. During forwarding, the ACLs are sequentially
evaluated until a match is found.

One reason to place filters in different regions is when they are added
with decreasing priorities and in an alternating order so that two
consecutive filters can never fit in the same region because of their
key usage.

In Spectrum-2 and newer ASICs the firmware started to report that the
maximum number of ACLs in a group is more than 16, but the layout of the
register that configures ACL groups (PAGT) was not updated to account
for that. It is therefore possible to hit stack corruption [1] in the
rare case where more than 16 ACLs in a group are required.

Fix by limiting the maximum ACL group size to the minimum between what
the firmware reports and the maximum ACLs that fit in the PAGT register.

Add a test case to make sure the machine does not crash when this
condition is hit.

[1]
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120
[...]
 dump_stack_lvl+0x36/0x50
 panic+0x305/0x330
 __stack_chk_fail+0x15/0x20
 mlxsw_sp_acl_tcam_group_update+0x116/0x120
 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110
 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20
 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0
 mlxsw_sp_acl_rule_add+0x47/0x240
 mlxsw_sp_flower_replace+0x1a9/0x1d0
 tc_setup_cb_add+0xdc/0x1c0
 fl_hw_replace_filter+0x146/0x1f0
 fl_change+0xc17/0x1360
 tc_new_tfilter+0x472/0xb90
 rtnetlink_rcv_msg+0x313/0x3b0
 netlink_rcv_skb+0x58/0x100
 netlink_unicast+0x244/0x390
 netlink_sendmsg+0x1e4/0x440
 ____sys_sendmsg+0x164/0x260
 ___sys_sendmsg+0x9a/0xe0
 __sys_sendmsg+0x7a/0xc0
 do_syscall_64+0x40/0xe0
 entry_SYSCALL_64_after_hwframe+0x63/0x6b</Note>
    </Notes>
    <CVE>CVE-2024-26586</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS

For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off
for validation. However, variable offset ptr alu is not prohibited
for this ptr kind. So the variable offset is not checked.

The following prog is accepted:

  func#0 @0
  0: R1=ctx() R10=fp0
  0: (bf) r6 = r1                       ; R1=ctx() R6_w=ctx()
  1: (79) r7 = *(u64 *)(r6 +144)        ; R6_w=ctx() R7_w=flow_keys()
  2: (b7) r8 = 1024                     ; R8_w=1024
  3: (37) r8 /= 1                       ; R8_w=scalar()
  4: (57) r8 &amp;= 1024                    ; R8_w=scalar(smin=smin32=0,
  smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400))
  5: (0f) r7 += r8
  mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1
  mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &amp;= 1024
  mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1
  mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024
  6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off
  =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024,
  var_off=(0x0; 0x400))
  6: (79) r0 = *(u64 *)(r7 +0)          ; R0_w=scalar()
  7: (95) exit

This prog loads flow_keys to r7, and adds the variable offset r8
to r7, and finally causes out-of-bounds access:

  BUG: unable to handle page fault for address: ffffc90014c80038
  [...]
  Call Trace:
   &lt;TASK&gt;
   bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline]
   __bpf_prog_run include/linux/filter.h:651 [inline]
   bpf_prog_run include/linux/filter.h:658 [inline]
   bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline]
   bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991
   bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359
   bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline]
   __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
   __do_sys_bpf kernel/bpf/syscall.c:5561 [inline]
   __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
   __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559
   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
   do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83
   entry_SYSCALL_64_after_hwframe+0x63/0x6b

Fix this by rejecting ptr alu with variable offset on flow_keys.
Applying the patch rejects the program with "R7 pointer arithmetic
on flow_keys prohibited".</Note>
    </Notes>
    <CVE>CVE-2024-26589</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix re-attachment branch in bpf_tracing_prog_attach

The following case can cause a crash due to missing attach_btf:

1) load rawtp program
2) load fentry program with rawtp as target_fd
3) create tracing link for fentry program with target_fd = 0
4) repeat 3

In the end we have:

- prog-&gt;aux-&gt;dst_trampoline == NULL
- tgt_prog == NULL (because we did not provide target_fd to link_create)
- prog-&gt;aux-&gt;attach_btf == NULL (the program was loaded with attach_prog_fd=X)
- the program was loaded for tgt_prog but we have no way to find out which one

    BUG: kernel NULL pointer dereference, address: 0000000000000058
    Call Trace:
     &lt;TASK&gt;
     ? __die+0x20/0x70
     ? page_fault_oops+0x15b/0x430
     ? fixup_exception+0x22/0x330
     ? exc_page_fault+0x6f/0x170
     ? asm_exc_page_fault+0x22/0x30
     ? bpf_tracing_prog_attach+0x279/0x560
     ? btf_obj_id+0x5/0x10
     bpf_tracing_prog_attach+0x439/0x560
     __sys_bpf+0x1cf4/0x2de0
     __x64_sys_bpf+0x1c/0x30
     do_syscall_64+0x41/0xf0
     entry_SYSCALL_64_after_hwframe+0x6e/0x76

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

i2c: i801: Fix block process call transactions

According to the Intel datasheets, software must reset the block
buffer index twice for block process call transactions: once before
writing the outgoing data to the buffer, and once again before
reading the incoming data from the buffer.

The driver is currently missing the second reset, causing the wrong
portion of the block buffer to be read.</Note>
    </Notes>
    <CVE>CVE-2024-26593</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 NULL pointer dereference in error path

When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after
failing to attach the region to an ACL group, we hit a NULL pointer
dereference upon 'region-&gt;group-&gt;tcam' [1].

Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam().

[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0
[...]
Call Trace:
 mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20
 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0
 mlxsw_sp_acl_rule_add+0x47/0x240
 mlxsw_sp_flower_replace+0x1a9/0x1d0
 tc_setup_cb_add+0xdc/0x1c0
 fl_hw_replace_filter+0x146/0x1f0
 fl_change+0xc17/0x1360
 tc_new_tfilter+0x472/0xb90
 rtnetlink_rcv_msg+0x313/0x3b0
 netlink_rcv_skb+0x58/0x100
 netlink_unicast+0x244/0x390
 netlink_sendmsg+0x1e4/0x440
 ____sys_sendmsg+0x164/0x260
 ___sys_sendmsg+0x9a/0xe0
 __sys_sendmsg+0x7a/0xc0
 do_syscall_64+0x40/0xe0
 entry_SYSCALL_64_after_hwframe+0x63/0x6b</Note>
    </Notes>
    <CVE>CVE-2024-26595</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: vgic-its: Avoid potential UAF in LPI translation cache

There is a potential UAF scenario in the case of an LPI translation
cache hit racing with an operation that invalidates the cache, such
as a DISCARD ITS command. The root of the problem is that
vgic_its_check_cache() does not elevate the refcount on the vgic_irq
before dropping the lock that serializes refcount changes.

Have vgic_its_check_cache() raise the refcount on the returned vgic_irq
and add the corresponding decrement after queueing the interrupt.</Note>
    </Notes>
    <CVE>CVE-2024-26598</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:

phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP

If the external phy working together with phy-omap-usb2 does not implement
send_srp(), we may still attempt to call it. This can happen on an idle
Ethernet gadget triggering a wakeup for example:

configfs-gadget.g1 gadget.0: ECM Suspend
configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup
...
Unable to handle kernel NULL pointer dereference at virtual address
00000000 when execute
...
PC is at 0x0
LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc]
...
musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core]
usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether]
eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c
dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4
sch_direct_xmit from __dev_queue_xmit+0x334/0xd88
__dev_queue_xmit from arp_solicit+0xf0/0x268
arp_solicit from neigh_probe+0x54/0x7c
neigh_probe from __neigh_event_send+0x22c/0x47c
__neigh_event_send from neigh_resolve_output+0x14c/0x1c0
neigh_resolve_output from ip_finish_output2+0x1c8/0x628
ip_finish_output2 from ip_send_skb+0x40/0xd8
ip_send_skb from udp_send_skb+0x124/0x340
udp_send_skb from udp_sendmsg+0x780/0x984
udp_sendmsg from __sys_sendto+0xd8/0x158
__sys_sendto from ret_fast_syscall+0x0/0x58

Let's fix the issue by checking for send_srp() and set_vbus() before
calling them. For USB peripheral only cases these both could be NULL.</Note>
    </Notes>
    <CVE>CVE-2024-26600</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: regenerate buddy after block freeing failed if under fc replay

This mostly reverts commit 6bd97bf273bd ("ext4: remove redundant
mb_regenerate_buddy()") and reintroduces mb_regenerate_buddy(). Based on
code in mb_free_blocks(), fast commit replay can end up marking as free
blocks that are already marked as such. This causes corruption of the
buddy bitmap so we need to regenerate it in that case.</Note>
    </Notes>
    <CVE>CVE-2024-26601</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/membarrier: reduce the ability to hammer on sys_membarrier

On some systems, sys_membarrier can be very expensive, causing overall
slowdowns for everything.  So put a lock on the path in order to
serialize the accesses to prevent the ability for this to be called at
too high of a frequency and saturate the machine.</Note>
    </Notes>
    <CVE>CVE-2024-26602</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Stop relying on userspace for info to fault in xsave buffer

Before this change, the expected size of the user space buffer was
taken from fx_sw-&gt;xstate_size. fx_sw-&gt;xstate_size can be changed
from user-space, so it is possible construct a sigreturn frame where:

 * fx_sw-&gt;xstate_size is smaller than the size required by valid bits in
   fx_sw-&gt;xfeatures.
 * user-space unmaps parts of the sigrame fpu buffer so that not all of
   the buffer required by xrstor is accessible.

In this case, xrstor tries to restore and accesses the unmapped area
which results in a fault. But fault_in_readable succeeds because buf +
fx_sw-&gt;xstate_size is within the still mapped area, so it goes back and
tries xrstor again. It will spin in this loop forever.

Instead, fault in the maximum size which can be touched by XRSTOR (taken
from fpstate-&gt;user_size).

[ dhansen: tweak subject / changelog ]</Note>
    </Notes>
    <CVE>CVE-2024-26603</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: sii902x: Fix probing race issue

A null pointer dereference crash has been observed rarely on TI
platforms using sii9022 bridge:

[   53.271356]  sii902x_get_edid+0x34/0x70 [sii902x]
[   53.276066]  sii902x_bridge_get_edid+0x14/0x20 [sii902x]
[   53.281381]  drm_bridge_get_edid+0x20/0x34 [drm]
[   53.286305]  drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper]
[   53.292955]  drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper]
[   53.300510]  drm_client_modeset_probe+0x1f0/0xbd4 [drm]
[   53.305958]  __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper]
[   53.313611]  drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper]
[   53.320039]  drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper]
[   53.326401]  drm_client_register+0x5c/0xa0 [drm]
[   53.331216]  drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper]
[   53.336881]  tidss_probe+0x128/0x264 [tidss]
[   53.341174]  platform_probe+0x68/0xc4
[   53.344841]  really_probe+0x188/0x3c4
[   53.348501]  __driver_probe_device+0x7c/0x16c
[   53.352854]  driver_probe_device+0x3c/0x10c
[   53.357033]  __device_attach_driver+0xbc/0x158
[   53.361472]  bus_for_each_drv+0x88/0xe8
[   53.365303]  __device_attach+0xa0/0x1b4
[   53.369135]  device_initial_probe+0x14/0x20
[   53.373314]  bus_probe_device+0xb0/0xb4
[   53.377145]  deferred_probe_work_func+0xcc/0x124
[   53.381757]  process_one_work+0x1f0/0x518
[   53.385770]  worker_thread+0x1e8/0x3dc
[   53.389519]  kthread+0x11c/0x120
[   53.392750]  ret_from_fork+0x10/0x20

The issue here is as follows:

- tidss probes, but is deferred as sii902x is still missing.
- sii902x starts probing and enters sii902x_init().
- sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from
  DRM's perspective.
- sii902x calls sii902x_audio_codec_init() and
  platform_device_register_data()
- The registration of the audio platform device causes probing of the
  deferred devices.
- tidss probes, which eventually causes sii902x_bridge_get_edid() to be
  called.
- sii902x_bridge_get_edid() tries to use the i2c to read the edid.
  However, the sii902x driver has not set up the i2c part yet, leading
  to the crash.

Fix this by moving the drm_bridge_add() to the end of the
sii902x_init(), which is also at the very end of sii902x_probe().</Note>
    </Notes>
    <CVE>CVE-2024-26607</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: fix a memory corruption

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

tcp: make sure init the accept_queue's spinlocks once

When I run syz's reproduction C program locally, it causes the following
issue:
pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!
WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7
30 20 ce 8f e8 ad 56 42 ff &lt;0f&gt; 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90
RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900
RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff
R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000
R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000
FS:  00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0
Call Trace:
&lt;IRQ&gt;
  _raw_spin_unlock (kernel/locking/spinlock.c:186)
  inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)
  inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358)
  tcp_check_req (net/ipv4/tcp_minisocks.c:868)
  tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260)
  ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)
  ip_local_deliver_finish (net/ipv4/ip_input.c:234)
  __netif_receive_skb_one_core (net/core/dev.c:5529)
  process_backlog (./include/linux/rcupdate.h:779)
  __napi_poll (net/core/dev.c:6533)
  net_rx_action (net/core/dev.c:6604)
  __do_softirq (./arch/x86/include/asm/jump_label.h:27)
  do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)
&lt;/IRQ&gt;
&lt;TASK&gt;
  __local_bh_enable_ip (kernel/softirq.c:381)
  __dev_queue_xmit (net/core/dev.c:4374)
  ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235)
  __ip_queue_xmit (net/ipv4/ip_output.c:535)
  __tcp_transmit_skb (net/ipv4/tcp_output.c:1462)
  tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)
  tcp_rcv_state_process (net/ipv4/tcp_input.c:6657)
  tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929)
  __release_sock (./include/net/sock.h:1121 net/core/sock.c:2968)
  release_sock (net/core/sock.c:3536)
  inet_wait_for_connect (net/ipv4/af_inet.c:609)
  __inet_stream_connect (net/ipv4/af_inet.c:702)
  inet_stream_connect (net/ipv4/af_inet.c:748)
  __sys_connect (./include/linux/file.h:45 net/socket.c:2064)
  __x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070)
  do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82)
  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
  RIP: 0033:0x7fa10ff05a3d
  Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89
  c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48
  RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a
  RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d
  RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003
  RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640
  R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20
&lt;/TASK&gt;

The issue triggering process is analyzed as follows:
Thread A                                       Thread B
tcp_v4_rcv	//receive ack TCP packet       inet_shutdown
  tcp_check_req                                  tcp_disconnect //disconnect sock
  ...                                              tcp_set_state(sk, TCP_CLOSE)
    inet_csk_complete_hashdance                ...
      inet_csk_reqsk_queue_add         
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26614</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

tomoyo: fix UAF write bug in tomoyo_write_control()

Since tomoyo_write_control() updates head-&gt;write_buf when write()
of long lines is requested, we need to fetch head-&gt;write_buf after
head-&gt;io_sem is held.  Otherwise, concurrent write() requests can
cause use-after-free-write and double-free problems.</Note>
    </Notes>
    <CVE>CVE-2024-26622</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:

netfilter: nf_tables: disallow anonymous set with timeout flag

Anonymous sets are never used with timeout from userspace, reject this.
Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.</Note>
    </Notes>
    <CVE>CVE-2024-26642</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

xen/events: close evtchn after mapping cleanup

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

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

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

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

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

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

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

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

ceph: prevent use-after-free in encode_cap_msg()

In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was
caught by KASAN at this line - 'ceph_buffer_get(arg-&gt;xattr_buf);'. This
implies before the refcount could be increment here, it was freed.

In same file, in "handle_cap_grant()" refcount is decremented by this
line - 'ceph_buffer_put(ci-&gt;i_xattrs.blob);'. It appears that a race
occurred and resource was freed by the latter line before the former
line could increment it.

encode_cap_msg() is called by __send_cap() and __send_cap() is called by
ceph_check_caps() after calling __prep_cap(). __prep_cap() is where
arg-&gt;xattr_buf is assigned to ci-&gt;i_xattrs.blob. This is the spot where
the refcount must be increased to prevent "use after free" error.</Note>
    </Notes>
    <CVE>CVE-2024-26689</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

ext4: fix double-free of blocks due to wrong extents moved_len

In ext4_move_extents(), moved_len is only updated when all moves are
successfully executed, and only discards orig_inode and donor_inode
preallocations when moved_len is not zero. When the loop fails to exit
after successfully moving some extents, moved_len is not updated and
remains at 0, so it does not discard the preallocations.

If the moved extents overlap with the preallocated extents, the
overlapped extents are freed twice in ext4_mb_release_inode_pa() and
ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4:
Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is
incremented twice. Hence when trim is executed, a zero-division bug is
triggered in mb_update_avg_fragment_size() because bb_free is not zero
and bb_fragments is zero.

Therefore, update move_len after each extent move to avoid the issue.</Note>
    </Notes>
    <CVE>CVE-2024-26704</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

arp: Prevent overflow in arp_req_get().

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

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

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

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

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

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

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

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

net/sched: act_mirred: don't override retval if we already lost the skb

If we're redirecting the skb, and haven't called tcf_mirred_forward(),
yet, we need to tell the core to drop the skb by setting the retcode
to SHOT. If we have called tcf_mirred_forward(), however, the skb
is out of our hands and returning SHOT will lead to UaF.

Move the retval override to the error path which actually need it.</Note>
    </Notes>
    <CVE>CVE-2024-26739</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: IOMMU table is not initialized for kdump over SR-IOV

When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due
to NULL pointer exception:

  Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
  BUG: Kernel NULL pointer dereference on read at 0x00000000
  Faulting instruction address: 0xc000000020847ad4
  Oops: Kernel access of bad area, sig: 11 [#1]
  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
  Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop
  CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12
  Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries
  NIP:  c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c
  REGS: c000000029162ca0 TRAP: 0300   Not tainted  (6.4.0-Test102+)
  MSR:  800000000280b033 &lt;SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE&gt;  CR: 48288244  XER: 00000008
  CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1
  ...
  NIP _find_next_zero_bit+0x24/0x110
  LR  bitmap_find_next_zero_area_off+0x5c/0xe0
  Call Trace:
    dev_printk_emit+0x38/0x48 (unreliable)
    iommu_area_alloc+0xc4/0x180
    iommu_range_alloc+0x1e8/0x580
    iommu_alloc+0x60/0x130
    iommu_alloc_coherent+0x158/0x2b0
    dma_iommu_alloc_coherent+0x3c/0x50
    dma_alloc_attrs+0x170/0x1f0
    mlx5_cmd_init+0xc0/0x760 [mlx5_core]
    mlx5_function_setup+0xf0/0x510 [mlx5_core]
    mlx5_init_one+0x84/0x210 [mlx5_core]
    probe_one+0x118/0x2c0 [mlx5_core]
    local_pci_probe+0x68/0x110
    pci_call_probe+0x68/0x200
    pci_device_probe+0xbc/0x1a0
    really_probe+0x104/0x540
    __driver_probe_device+0xb4/0x230
    driver_probe_device+0x54/0x130
    __driver_attach+0x158/0x2b0
    bus_for_each_dev+0xa8/0x130
    driver_attach+0x34/0x50
    bus_add_driver+0x16c/0x300
    driver_register+0xa4/0x1b0
    __pci_register_driver+0x68/0x80
    mlx5_init+0xb8/0x100 [mlx5_core]
    do_one_initcall+0x60/0x300
    do_init_module+0x7c/0x2b0

At the time of LPAR dump, before kexec hands over control to kdump
kernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT.
For the SR-IOV case, default DMA window "ibm,dma-window" is removed from
the FDT and DDW added, for the device.

Now, kexec hands over control to the kdump kernel.

When the kdump kernel initializes, PCI busses are scanned and IOMMU
group/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV
case, there is no "ibm,dma-window". The original commit: b1fc44eaa9ba,
fixes the path where memory is pre-mapped (direct mapped) to the DDW.
When TCEs are direct mapped, there is no need to initialize IOMMU
tables.

iommu_table_setparms_lpar() only considers "ibm,dma-window" property
when initiallizing IOMMU table. In the scenario where TCEs are
dynamically allocated for SR-IOV, newly created IOMMU table is not
initialized. Later, when the device driver tries to enter TCEs for the
SR-IOV device, NULL pointer execption is thrown from iommu_area_alloc().

The fix is to initialize the IOMMU table with DDW property stored in the
FDT. There are 2 points to remember:

	1. For the dedicated adapter, kdump kernel would encounter both
	   default and DDW in FDT. In this case, DDW property is used to
	   initialize the IOMMU table.

	2. A DDW could be direct or dynamic mapped. kdump kernel would
	   initialize IOMMU table and mark the existing DDW as
	   "dynamic". This works fine since, at the time of table
	   initialization, iommu_table_clear() makes some space in the
	   DDW, for some predefined number of TCEs which are needed for
	   kdump to succeed.</Note>
    </Notes>
    <CVE>CVE-2024-26745</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio

If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the
following kernel warning appears:

WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8
Call trace:
 kiocb_set_cancel_fn+0x9c/0xa8
 ffs_epfile_read_iter+0x144/0x1d0
 io_read+0x19c/0x498
 io_issue_sqe+0x118/0x27c
 io_submit_sqes+0x25c/0x5fc
 __arm64_sys_io_uring_enter+0x104/0xab0
 invoke_syscall+0x58/0x11c
 el0_svc_common+0xb4/0xf4
 do_el0_svc+0x2c/0xb0
 el0_svc+0x2c/0xa4
 el0t_64_sync_handler+0x68/0xb4
 el0t_64_sync+0x1a4/0x1a8

Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is
submitted by libaio.</Note>
    </Notes>
    <CVE>CVE-2024-26764</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: Fix sdma.h tx-&gt;num_descs off-by-one error

Unfortunately the commit `fd8958efe877` introduced another error
causing the `descs` array to overflow. This reults in further crashes
easily reproducible by `sendmsg` system call.

[ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI
[ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1]
--
[ 1080.974535] Call Trace:
[ 1080.976990]  &lt;TASK&gt;
[ 1081.021929]  hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1]
[ 1081.027364]  hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1]
[ 1081.032633]  hfi1_ipoib_send+0x112/0x300 [hfi1]
[ 1081.042001]  ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib]
[ 1081.046978]  dev_hard_start_xmit+0xc4/0x210
--
[ 1081.148347]  __sys_sendmsg+0x59/0xa0

crash&gt; ipoib_txreq 0xffff9cfeba229f00
struct ipoib_txreq {
  txreq = {
    list = {
      next = 0xffff9cfeba229f00,
      prev = 0xffff9cfeba229f00
    },
    descp = 0xffff9cfeba229f40,
    coalesce_buf = 0x0,
    wait = 0xffff9cfea4e69a48,
    complete = 0xffffffffc0fe0760 &lt;hfi1_ipoib_sdma_complete&gt;,
    packet_len = 0x46d,
    tlen = 0x0,
    num_desc = 0x0,
    desc_limit = 0x6,
    next_descq_idx = 0x45c,
    coalesce_idx = 0x0,
    flags = 0x0,
    descs = {{
        qw = {0x8024000120dffb00, 0x4}  # SDMA_DESC0_FIRST_DESC_FLAG (bit 63)
      }, {
        qw = {  0x3800014231b108, 0x4}
      }, {
        qw = { 0x310000e4ee0fcf0, 0x8}
      }, {
        qw = {  0x3000012e9f8000, 0x8}
      }, {
        qw = {  0x59000dfb9d0000, 0x8}
      }, {
        qw = {  0x78000e02e40000, 0x8}
      }}
  },
  sdma_hdr =  0x400300015528b000,  &lt;&lt;&lt; invalid pointer in the tx request structure
  sdma_status = 0x0,                   SDMA_DESC0_LAST_DESC_FLAG (bit 62)
  complete = 0x0,
  priv = 0x0,
  txq = 0xffff9cfea4e69880,
  skb = 0xffff9d099809f400
}

If an SDMA send consists of exactly 6 descriptors and requires dword
padding (in the 7th descriptor), the sdma_txreq descriptor array is not
properly expanded and the packet will overflow into the container
structure. This results in a panic when the send completion runs. The
exact panic varies depending on what elements of the container structure
get corrupted. The fix is to use the correct expression in
_pad_sdma_tx_descs() to test the need to expand the descriptor array.

With this patch the crashes are no longer reproducible and the machine is
stable.</Note>
    </Notes>
    <CVE>CVE-2024-26766</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:

ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()

Determine if the group block bitmap is corrupted before using ac_b_ex in
ext4_mb_try_best_found() to avoid allocating blocks from a group with a
corrupted block bitmap in the following concurrency and making the
situation worse.

ext4_mb_regular_allocator
  ext4_lock_group(sb, group)
  ext4_mb_good_group
   // check if the group bbitmap is corrupted
  ext4_mb_complex_scan_group
   // Scan group gets ac_b_ex but doesn't use it
  ext4_unlock_group(sb, group)
                           ext4_mark_group_bitmap_corrupted(group)
                           // The block bitmap was corrupted during
                           // the group unlock gap.
  ext4_mb_try_best_found
    ext4_lock_group(ac-&gt;ac_sb, group)
    ext4_mb_use_best_found
      mb_mark_used
      // Allocating blocks in block bitmap corrupted group</Note>
    </Notes>
    <CVE>CVE-2024-26773</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

x86, relocs: Ignore relocations in .notes section

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

To avoid leaking the KASLR base without breaking unprivileged tools that
are expecting to read /sys/kernel/notes, skip performing relocations in
the .notes section. The values readable in .notes are then identical to
those found in System.map.</Note>
    </Notes>
    <CVE>CVE-2024-26816</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

cachefiles: fix memory leak in cachefiles_add_cache()

The following memory leak was reported after unbinding /dev/cachefiles:

==================================================================
unreferenced object 0xffff9b674176e3c0 (size 192):
  comm "cachefilesd2", pid 680, jiffies 4294881224
  hex dump (first 32 bytes):
    01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc ea38a44b):
    [&lt;ffffffff8eb8a1a5&gt;] kmem_cache_alloc+0x2d5/0x370
    [&lt;ffffffff8e917f86&gt;] prepare_creds+0x26/0x2e0
    [&lt;ffffffffc002eeef&gt;] cachefiles_determine_cache_security+0x1f/0x120
    [&lt;ffffffffc00243ec&gt;] cachefiles_add_cache+0x13c/0x3a0
    [&lt;ffffffffc0025216&gt;] cachefiles_daemon_write+0x146/0x1c0
    [&lt;ffffffff8ebc4a3b&gt;] vfs_write+0xcb/0x520
    [&lt;ffffffff8ebc5069&gt;] ksys_write+0x69/0xf0
    [&lt;ffffffff8f6d4662&gt;] do_syscall_64+0x72/0x140
    [&lt;ffffffff8f8000aa&gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76
==================================================================

Put the reference count of cache_cred in cachefiles_daemon_unbind() to
fix the problem. And also put cache_cred in cachefiles_add_cache() error
branch to avoid memory leaks.</Note>
    </Notes>
    <CVE>CVE-2024-26840</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net/ipv6: avoid possible UAF in ip6_route_mpath_notify()

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

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

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

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

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

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

Freed by task 16:
  kasan_save_stack mm/kasan/common.c:47 [inline]
  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
  kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640
  poison_slab_object+0xa6/0xe0 m
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-26852</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

packet: annotate data-races around ignore_outgoing

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

Add appropriate READ_ONCE()/WRITE_ONCE() annotations.

syzbot reported:

BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt

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

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

value changed: 0x00 -&gt; 0x01

Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G        W          6.8.0-syzkaller-08073-g480e035fc4c7 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet</Note>
    </Notes>
    <CVE>CVE-2024-26862</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

af_unix: Fix garbage collector racing against connect()

Garbage collector does not take into account the risk of embryo getting
enqueued during the garbage collection. If such embryo has a peer that
carries SCM_RIGHTS, two consecutive passes of scan_children() may see a
different set of children. Leading to an incorrectly elevated inflight
count, and then a dangling pointer within the gc_inflight_list.

sockets are AF_UNIX/SOCK_STREAM
S is an unconnected socket
L is a listening in-flight socket bound to addr, not in fdtable
V's fd will be passed via sendmsg(), gets inflight count bumped

connect(S, addr)	sendmsg(S, [V]); close(V)	__unix_gc()
----------------	-------------------------	-----------

NS = unix_create1()
skb1 = sock_wmalloc(NS)
L = unix_find_other(addr)
unix_state_lock(L)
unix_peer(S) = NS
			// V count=1 inflight=0

 			NS = unix_peer(S)
 			skb2 = sock_alloc()
			skb_queue_tail(NS, skb2[V])

			// V became in-flight
			// V count=2 inflight=1

			close(V)

			// V count=1 inflight=1
			// GC candidate condition met

						for u in gc_inflight_list:
						  if (total_refs == inflight_refs)
						    add u to gc_candidates

						// gc_candidates={L, V}

						for u in gc_candidates:
						  scan_children(u, dec_inflight)

						// embryo (skb1) was not
						// reachable from L yet, so V's
						// inflight remains unchanged
__skb_queue_tail(L, skb1)
unix_state_unlock(L)
						for u in gc_candidates:
						  if (u.inflight)
						    scan_children(u, inc_inflight_move_tail)

						// V count=1 inflight=2 (!)

If there is a GC-candidate listening socket, lock/unlock its state. This
makes GC wait until the end of any ongoing connect() to that socket. After
flipping the lock, a possibly SCM-laden embryo is already enqueued. And if
there is another embryo coming, it can not possibly carry SCM_RIGHTS. At
this point, unix_inflight() can not happen because unix_gc_lock is already
taken. Inflight graph remains unaffected.</Note>
    </Notes>
    <CVE>CVE-2024-26923</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

media: edia: dvbdev: fix a use-after-free

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

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

When calling dvb_unregister_device, dmxdev-&gt;dvbdev (i.e. *pdvbdev in
dvb_register_device) could point to memory that had been freed in
dvb_register_device. Thereafter, this pointer is transferred to
kref_put and triggering a use-after-free.</Note>
    </Notes>
    <CVE>CVE-2024-27043</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

pstore: inode: Only d_invalidate() is needed

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

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

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

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

Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout

When the sco connection is established and then, the sco socket
is releasing, timeout_work will be scheduled to judge whether
the sco disconnection is timeout. The sock will be deallocated
later, but it is dereferenced again in sco_sock_timeout. As a
result, the use-after-free bugs will happen. The root cause is
shown below:

    Cleanup Thread               |      Worker Thread
sco_sock_release                 |
  sco_sock_close                 |
    __sco_sock_close             |
      sco_sock_set_timer         |
        schedule_delayed_work    |
  sco_sock_kill                  |    (wait a time)
    sock_put(sk) //FREE          |  sco_sock_timeout
                                 |    sock_hold(sk) //USE

The KASAN report triggered by POC is shown below:

[   95.890016] ==================================================================
[   95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0
[   95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7
...
[   95.890755] Workqueue: events sco_sock_timeout
[   95.890755] Call Trace:
[   95.890755]  &lt;TASK&gt;
[   95.890755]  dump_stack_lvl+0x45/0x110
[   95.890755]  print_address_description+0x78/0x390
[   95.890755]  print_report+0x11b/0x250
[   95.890755]  ? __virt_addr_valid+0xbe/0xf0
[   95.890755]  ? sco_sock_timeout+0x5e/0x1c0
[   95.890755]  kasan_report+0x139/0x170
[   95.890755]  ? update_load_avg+0xe5/0x9f0
[   95.890755]  ? sco_sock_timeout+0x5e/0x1c0
[   95.890755]  kasan_check_range+0x2c3/0x2e0
[   95.890755]  sco_sock_timeout+0x5e/0x1c0
[   95.890755]  process_one_work+0x561/0xc50
[   95.890755]  worker_thread+0xab2/0x13c0
[   95.890755]  ? pr_cont_work+0x490/0x490
[   95.890755]  kthread+0x279/0x300
[   95.890755]  ? pr_cont_work+0x490/0x490
[   95.890755]  ? kthread_blkcg+0xa0/0xa0
[   95.890755]  ret_from_fork+0x34/0x60
[   95.890755]  ? kthread_blkcg+0xa0/0xa0
[   95.890755]  ret_from_fork_asm+0x11/0x20
[   95.890755]  &lt;/TASK&gt;
[   95.890755]
[   95.890755] Allocated by task 506:
[   95.890755]  kasan_save_track+0x3f/0x70
[   95.890755]  __kasan_kmalloc+0x86/0x90
[   95.890755]  __kmalloc+0x17f/0x360
[   95.890755]  sk_prot_alloc+0xe1/0x1a0
[   95.890755]  sk_alloc+0x31/0x4e0
[   95.890755]  bt_sock_alloc+0x2b/0x2a0
[   95.890755]  sco_sock_create+0xad/0x320
[   95.890755]  bt_sock_create+0x145/0x320
[   95.890755]  __sock_create+0x2e1/0x650
[   95.890755]  __sys_socket+0xd0/0x280
[   95.890755]  __x64_sys_socket+0x75/0x80
[   95.890755]  do_syscall_64+0xc4/0x1b0
[   95.890755]  entry_SYSCALL_64_after_hwframe+0x67/0x6f
[   95.890755]
[   95.890755] Freed by task 506:
[   95.890755]  kasan_save_track+0x3f/0x70
[   95.890755]  kasan_save_free_info+0x40/0x50
[   95.890755]  poison_slab_object+0x118/0x180
[   95.890755]  __kasan_slab_free+0x12/0x30
[   95.890755]  kfree+0xb2/0x240
[   95.890755]  __sk_destruct+0x317/0x410
[   95.890755]  sco_sock_release+0x232/0x280
[   95.890755]  sock_close+0xb2/0x210
[   95.890755]  __fput+0x37f/0x770
[   95.890755]  task_work_run+0x1ae/0x210
[   95.890755]  get_signal+0xe17/0xf70
[   95.890755]  arch_do_signal_or_restart+0x3f/0x520
[   95.890755]  syscall_exit_to_user_mode+0x55/0x120
[   95.890755]  do_syscall_64+0xd1/0x1b0
[   95.890755]  entry_SYSCALL_64_after_hwframe+0x67/0x6f
[   95.890755]
[   95.890755] The buggy address belongs to the object at ffff88800c388000
[   95.890755]  which belongs to the cache kmalloc-1k of size 1024
[   95.890755] The buggy address is located 128 bytes inside of
[   95.890755]  freed 1024-byte region [ffff88800c388000, ffff88800c388400)
[   95.890755]
[   95.890755] The buggy address belongs to the physical page:
[   95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388
[   95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
[   95.890755] ano
---truncated---</Note>
    </Notes>
    <CVE>CVE-2024-27398</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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:

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">wall in util-linux through 2.40, often installed with setgid tty permissions, allows escape sequences to be sent to other users' terminals through argv. (Specifically, escape sequences received from stdin are blocked, but escape sequences received from argv are not blocked.) There may be plausible scenarios where this leads to account takeover.</Note>
    </Notes>
    <CVE>CVE-2024-28085</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">nghttp2 is an implementation of the Hypertext Transfer Protocol version 2 in C. The nghttp2 library prior to version 1.61.0 keeps reading the unbounded number of HTTP/2 CONTINUATION frames even after a stream is reset to keep HPACK context in sync.  This causes excessive CPU usage to decode HPACK stream. nghttp2 v1.61.0 mitigates this vulnerability by limiting the number of CONTINUATION frames it accepts per stream. There is no workaround for this vulnerability.</Note>
    </Notes>
    <CVE>CVE-2024-28182</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">libexpat through 2.6.1 allows an XML Entity Expansion attack when there is isolated use of external parsers (created via XML_ExternalEntityParserCreate).</Note>
    </Notes>
    <CVE>CVE-2024-28757</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 GnuTLS. The Minerva attack is a cryptographic vulnerability that exploits deterministic behavior in systems like GnuTLS, leading to side-channel leaks. In specific scenarios, such as when using the GNUTLS_PRIVKEY_FLAG_REPRODUCIBLE flag, it can result in a noticeable step in nonce size from 513 to 512 bits, exposing a potential timing side-channel.</Note>
    </Notes>
    <CVE>CVE-2024-28834</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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 has been discovered in GnuTLS where an application crash can be induced when attempting to verify a specially crafted .pem bundle using the "certtool --verify-chain" command.</Note>
    </Notes>
    <CVE>CVE-2024-28835</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The iconv() function in the GNU C Library versions 2.39 and older may overflow the output buffer passed to it by up to 4 bytes when converting strings to the ISO-2022-CN-EXT character set, which may be used to crash an application or overwrite a neighbouring variable.
</Note>
    </Notes>
    <CVE>CVE-2024-2961</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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">Because of a logical error in XSA-407 (Branch Type Confusion), the
mitigation is not applied properly when it is intended to be used.
XSA-434 (Speculative Return Stack Overflow) uses the same
infrastructure, so is equally impacted.

For more details, see:
  https://xenbits.xen.org/xsa/advisory-407.html
  https://xenbits.xen.org/xsa/advisory-434.html
</Note>
    </Notes>
    <CVE>CVE-2024-31142</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">less through 653 allows OS command execution via a newline character in the name of a file, because quoting is mishandled in filename.c. Exploitation typically requires use with attacker-controlled file names, such as the files extracted from an untrusted archive. Exploitation also requires the LESSOPEN environment variable, but this is set by default in many common cases.</Note>
    </Notes>
    <CVE>CVE-2024-32487</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </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">Jinja is an extensible templating engine. The `xmlattr` filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, `/`, `&gt;`, or `=`, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the `xmlattr` filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting _values_ as user input continues to be safe. This vulnerability is fixed in 3.1.4.</Note>
    </Notes>
    <CVE>CVE-2024-34064</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability 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:

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:

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

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:

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">A vulnerability was identified in the kjd/idna library, specifically within the `idna.encode()` function, affecting version 3.6. The issue arises from the function's handling of crafted input strings, which can lead to quadratic complexity and consequently, a denial of service condition. This vulnerability is triggered by a crafted input that causes the `idna.encode()` function to process the input with considerable computational load, significantly increasing the processing time in a quadratic manner relative to the input size.</Note>
    </Notes>
    <CVE>CVE-2024-3651</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete

FFS based applications can utilize the aio_cancel() callback to dequeue
pending USB requests submitted to the UDC.  There is a scenario where the
FFS application issues an AIO cancel call, while the UDC is handling a
soft disconnect.  For a DWC3 based implementation, the callstack looks
like the following:

    DWC3 Gadget                               FFS Application
dwc3_gadget_soft_disconnect()              ...
  --&gt; dwc3_stop_active_transfers()
    --&gt; dwc3_gadget_giveback(-ESHUTDOWN)
      --&gt; ffs_epfile_async_io_complete()   ffs_aio_cancel()
        --&gt; usb_ep_free_request()            --&gt; usb_ep_dequeue()

There is currently no locking implemented between the AIO completion
handler and AIO cancel, so the issue occurs if the completion routine is
running in parallel to an AIO cancel call coming from the FFS application.
As the completion call frees the USB request (io_data-&gt;req) the FFS
application is also referencing it for the usb_ep_dequeue() call.  This can
lead to accessing a stale/hanging pointer.

commit b566d38857fc ("usb: gadget: f_fs: use io_data-&gt;status consistently")
relocated the usb_ep_free_request() into ffs_epfile_async_io_complete().
However, in order to properly implement locking to mitigate this issue, the
spinlock can't be added to ffs_epfile_async_io_complete(), as
usb_ep_dequeue() (if successfully dequeuing a USB request) will call the
function driver's completion handler in the same context.  Hence, leading
into a deadlock.

Fix this issue by moving the usb_ep_free_request() back to
ffs_user_copy_worker(), and ensuring that it explicitly sets io_data-&gt;req
to NULL after freeing it within the ffs-&gt;eps_lock.  This resolves the race
condition above, as the ffs_aio_cancel() routine will not continue
attempting to dequeue a request that has already been freed, or the
ffs_user_copy_work() not freeing the USB request until the AIO cancel is
done referencing it.

This fix depends on
  commit b566d38857fc ("usb: gadget: f_fs: use io_data-&gt;status
  consistently")</Note>
    </Notes>
    <CVE>CVE-2024-36894</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

gpiolib: cdev: Fix use after free in lineinfo_changed_notify

The use-after-free issue occurs as follows: when the GPIO chip device file
is being closed by invoking gpio_chrdev_release(), watched_lines is freed
by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier
chain failed due to waiting write rwsem. Additionally, one of the GPIO
chip's lines is also in the release process and holds the notifier chain's
read rwsem. Consequently, a race condition leads to the use-after-free of
watched_lines.

Here is the typical stack when issue happened:

[free]
gpio_chrdev_release()
  --&gt; bitmap_free(cdev-&gt;watched_lines)                  &lt;-- freed
  --&gt; blocking_notifier_chain_unregister()
    --&gt; down_write(&amp;nh-&gt;rwsem)                          &lt;-- waiting rwsem
          --&gt; __down_write_common()
            --&gt; rwsem_down_write_slowpath()
                  --&gt; schedule_preempt_disabled()
                    --&gt; schedule()

[use]
st54spi_gpio_dev_release()
  --&gt; gpio_free()
    --&gt; gpiod_free()
      --&gt; gpiod_free_commit()
        --&gt; gpiod_line_state_notify()
          --&gt; blocking_notifier_call_chain()
            --&gt; down_read(&amp;nh-&gt;rwsem);                  &lt;-- held rwsem
            --&gt; notifier_call_chain()
              --&gt; lineinfo_changed_notify()
                --&gt; test_bit(xxxx, cdev-&gt;watched_lines) &lt;-- use after free

The side effect of the use-after-free issue is that a GPIO line event is
being generated for userspace where it shouldn't. However, since the chrdev
is being closed, userspace won't have the chance to read that event anyway.

To fix the issue, call the bitmap_free() function after the unregistration
of lineinfo_changed_nb notifier chain.</Note>
    </Notes>
    <CVE>CVE-2024-36899</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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: Use refcount_inc_not_zero() in tcp_twsk_unique().

Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique()
with nice analysis.

Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for
timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's
sk_refcnt after putting it into ehash and releasing the bucket lock.

Thus, there is a small race window where other threads could try to
reuse the port during connect() and call sock_hold() in tcp_twsk_unique()
for the TIME-WAIT socket with zero refcnt.

If that happens, the refcnt taken by tcp_twsk_unique() is overwritten
and sock_put() will cause underflow, triggering a real use-after-free
somewhere else.

To avoid the use-after-free, we need to use refcount_inc_not_zero() in
tcp_twsk_unique() and give up on reusing the port if it returns false.

[0]:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110
CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1
Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023
RIP: 0010:refcount_warn_saturate+0xe5/0x110
Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff &lt;0f&gt; 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8
RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027
RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0
RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0
R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84
R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0
FS:  00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? refcount_warn_saturate+0xe5/0x110
 ? __warn+0x81/0x130
 ? refcount_warn_saturate+0xe5/0x110
 ? report_bug+0x171/0x1a0
 ? refcount_warn_saturate+0xe5/0x110
 ? handle_bug+0x3c/0x80
 ? exc_invalid_op+0x17/0x70
 ? asm_exc_invalid_op+0x1a/0x20
 ? refcount_warn_saturate+0xe5/0x110
 tcp_twsk_unique+0x186/0x190
 __inet_check_established+0x176/0x2d0
 __inet_hash_connect+0x74/0x7d0
 ? __pfx___inet_check_established+0x10/0x10
 tcp_v4_connect+0x278/0x530
 __inet_stream_connect+0x10f/0x3d0
 inet_stream_connect+0x3a/0x60
 __sys_connect+0xa8/0xd0
 __x64_sys_connect+0x18/0x20
 do_syscall_64+0x83/0x170
 entry_SYSCALL_64_after_hwframe+0x78/0x80
RIP: 0033:0x7f62c11a885d
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d a3 45 0c 00 f7 d8 64 89 01 48
RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d
RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003
RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0
R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0
 &lt;/TASK&gt;</Note>
    </Notes>
    <CVE>CVE-2024-36904</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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:

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:

fs/9p: only translate RWX permissions for plain 9P2000

Garbage in plain 9P2000's perm bits is allowed through, which causes it
to be able to set (among others) the suid bit. This was presumably not
the intent since the unix extended bits are handled explicitly and
conditionally on .u.</Note>
    </Notes>
    <CVE>CVE-2024-36964</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>important</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

net: fix __dst_negative_advice() race

__dst_negative_advice() does not enforce proper RCU rules when
sk-&gt;dst_cache must be cleared, leading to possible UAF.

RCU rules are that we must first clear sk-&gt;sk_dst_cache,
then call dst_release(old_dst).

Note that sk_dst_reset(sk) is implementing this protocol correctly,
while __dst_negative_advice() uses the wrong order.

Given that ip6_negative_advice() has special logic
against RTF_CACHE, this means each of the three -&gt;negative_advice()
existing methods must perform the sk_dst_reset() themselves.

Note the check against NULL dst is centralized in
__dst_negative_advice(), there is no need to duplicate
it in various callbacks.

Many thanks to Clement Lecigne for tracking this issue.

This old bug became visible after the blamed commit, using UDP sockets.</Note>
    </Notes>
    <CVE>CVE-2024-36971</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="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">In the Linux kernel, the following vulnerability has been resolved:

of: module: add buffer overflow check in of_modalias()

In of_modalias(), if the buffer happens to be too small even for the 1st
snprintf() call, the len parameter will become negative and str parameter
(if not NULL initially) will point beyond the buffer's end. Add the buffer
overflow check after the 1st snprintf() call and fix such check after the
strlen() call (accounting for the terminating NUL char).</Note>
    </Notes>
    <CVE>CVE-2024-38541</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

RDMA/hns: Fix UAF for cq async event

The refcount of CQ is not protected by locks. When CQ asynchronous
events and CQ destruction are concurrent, CQ may have been released,
which will cause UAF.

Use the xa_lock() to protect the CQ refcount.</Note>
    </Notes>
    <CVE>CVE-2024-38545</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: qedf: Ensure the copied buf is NUL terminated

Currently, we allocate a count-sized kernel buffer and copy count from
userspace to that buffer. Later, we use kstrtouint on this buffer but we
don't ensure that the string is terminated inside the buffer, this can
lead to OOB read when using kstrtouint. Fix this issue by using
memdup_user_nul instead of memdup_user.</Note>
    </Notes>
    <CVE>CVE-2024-38559</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:

scsi: bfa: Ensure the copied buf is NUL terminated

Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from
userspace to that buffer. Later, we use sscanf on this buffer but we don't
ensure that the string is terminated inside the buffer, this can lead to
OOB read when using sscanf. Fix this issue by using memdup_user_nul instead
of memdup_user.</Note>
    </Notes>
    <CVE>CVE-2024-38560</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" 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 BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE

bpf_prog_attach uses attach_type_to_prog_type to enforce proper
attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses
bpf_prog_get and relies on bpf_prog_attach_check_attach_type
to properly verify prog_type &lt;&gt; attach_type association.

Add missing attach_type enforcement for the link_create case.
Otherwise, it's currently possible to attach cgroup_skb prog
types to other cgroup hooks.</Note>
    </Notes>
    <CVE>CVE-2024-38564</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:

ecryptfs: Fix buffer size for tag 66 packet

The 'TAG 66 Packet Format' description is missing the cipher code and
checksum fields that are packed into the message packet. As a result,
the buffer allocated for the packet is 3 bytes too small and
write_tag_66_packet() will write up to 3 bytes past the end of the
buffer.

Fix this by increasing the size of the allocation so the whole packet
will always fit in the buffer.

This fixes the below kasan slab-out-of-bounds bug:

  BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0
  Write of size 1 at addr ffff88800afbb2a5 by task touch/181

  CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x4c/0x70
   print_report+0xc5/0x610
   ? ecryptfs_generate_key_packet_set+0x7d6/0xde0
   ? kasan_complete_mode_report_info+0x44/0x210
   ? ecryptfs_generate_key_packet_set+0x7d6/0xde0
   kasan_report+0xc2/0x110
   ? ecryptfs_generate_key_packet_set+0x7d6/0xde0
   __asan_store1+0x62/0x80
   ecryptfs_generate_key_packet_set+0x7d6/0xde0
   ? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10
   ? __alloc_pages+0x2e2/0x540
   ? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d]
   ? dentry_open+0x8f/0xd0
   ecryptfs_write_metadata+0x30a/0x550
   ? __pfx_ecryptfs_write_metadata+0x10/0x10
   ? ecryptfs_get_lower_file+0x6b/0x190
   ecryptfs_initialize_file+0x77/0x150
   ecryptfs_create+0x1c2/0x2f0
   path_openat+0x17cf/0x1ba0
   ? __pfx_path_openat+0x10/0x10
   do_filp_open+0x15e/0x290
   ? __pfx_do_filp_open+0x10/0x10
   ? __kasan_check_write+0x18/0x30
   ? _raw_spin_lock+0x86/0xf0
   ? __pfx__raw_spin_lock+0x10/0x10
   ? __kasan_check_write+0x18/0x30
   ? alloc_fd+0xf4/0x330
   do_sys_openat2+0x122/0x160
   ? __pfx_do_sys_openat2+0x10/0x10
   __x64_sys_openat+0xef/0x170
   ? __pfx___x64_sys_openat+0x10/0x10
   do_syscall_64+0x60/0xd0
   entry_SYSCALL_64_after_hwframe+0x6e/0xd8
  RIP: 0033:0x7f00a703fd67
  Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f
  RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
  RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67
  RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c
  RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000
  R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941
  R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040
   &lt;/TASK&gt;

  Allocated by task 181:
   kasan_save_stack+0x2f/0x60
   kasan_set_track+0x29/0x40
   kasan_save_alloc_info+0x25/0x40
   __kasan_kmalloc+0xc5/0xd0
   __kmalloc+0x66/0x160
   ecryptfs_generate_key_packet_set+0x6d2/0xde0
   ecryptfs_write_metadata+0x30a/0x550
   ecryptfs_initialize_file+0x77/0x150
   ecryptfs_create+0x1c2/0x2f0
   path_openat+0x17cf/0x1ba0
   do_filp_open+0x15e/0x290
   do_sys_openat2+0x122/0x160
   __x64_sys_openat+0xef/0x170
   do_syscall_64+0x60/0xd0
   entry_SYSCALL_64_after_hwframe+0x6e/0xd8</Note>
    </Notes>
    <CVE>CVE-2024-38578</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>moderate</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">The "ipaddress" module contained incorrect information about whether certain IPv4 and IPv6 addresses were designated as "globally reachable" or "private". This affected the is_private and is_global properties of the ipaddress.IPv4Address, ipaddress.IPv4Network, ipaddress.IPv6Address, and ipaddress.IPv6Network classes, where values wouldn't be returned in accordance with the latest information from the IANA Special-Purpose Address Registries.

CPython 3.12.4 and 3.13.0a6 contain updated information from these registries and thus have the intended behavior.</Note>
    </Notes>
    <CVE>CVE-2024-4032</CVE>
    <ProductStatuses>
      <Status Type="Fixed"/>
    </ProductStatuses>
    <Threats>
      <Threat Type="Impact">
        <Description>low</Description>
      </Threat>
    </Threats>
  </Vulnerability>
  <Vulnerability xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1" Ordinal="1">
    <Notes>
      <Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">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>
