SUSE-IU-2024:1220-1 SUSE Image security@suse.de SUSE Security Team SUSE Image SUSE-IU-2024:1220-1 Interim 1 1 2025-07-09T15:43:13Z current 2024-09-13T01:00:00Z 2024-09-13T01:00:00Z cve-database/bin/generate-cvrf-publiccloud.pl 2021-02-18T01:00:00Z Image update for SUSE-IU-2024:1220-1 / google/sles-15-sp4-sap-byos-v20240913-x86-64 This image update for google/sles-15-sp4-sap-byos-v20240913-x86-64 contains the following changes: Package 000release-packages:SLES_SAP-release was updated: Package bind was updated: - Update to release 9.16.50 Bug Fixes: * A regression in cache-cleaning code enabled memory use to grow significantly more quickly than before, until the configured max-cache-size limit was reached. This has been fixed. * Using rndc flush inadvertently caused cache cleaning to become less effective. This could ultimately lead to the configured max-cache-size limit being exceeded and has now been fixed. * The logic for cleaning up expired cached DNS records was tweaked to be more aggressive. This change helps with enforcing max-cache-ttl and max-ncache-ttl in a timely manner. * It was possible to trigger a use-after-free assertion when the overmem cache cleaning was initiated. This has been fixed. New Features: * Added RESOLVER.ARPA to the built in empty zones. - Security Fixes: * It is possible to craft excessively large numbers of resource record types for a given owner name, which has the effect of slowing down database processing. This has been addressed by adding a configurable limit to the number of records that can be stored per name and type in a cache or zone database. The default is 100, which can be tuned with the new max-types-per-name option. (CVE-2024-1737) [bsc#1228256, bind-9.16-CVE-2024-1737.patch] * Validating DNS messages signed using the SIG(0) protocol (RFC 2931) could cause excessive CPU load, leading to a denial-of-service condition. Support for SIG(0) message validation was removed from this version of named. (CVE-2024-1975) [bsc#1228257, bind-9.16-CVE-2024-1975.patch] * When looking up the NS records of parent zones as part of looking up DS records, it was possible for named to trigger an assertion failure if serve-stale was enabled. This has been fixed. (CVE-2024-4076) [bsc#1228258, bind-9.16-CVE-2024-4076.patch] Package binutils was updated: - Update to current 2.43.1 branch [PED-10474]: * PR32109 - fuzzing problem * PR32083 - LTO vs overridden common symbols * PR32067 - crash with LTO-plugin and --oformat=binary * PR31956 - LTO vs wrapper symbols * riscv - add Zimop and Zcmop extensions - Adjusted binutils-2.43-branch.diff.gz. - Update to version 2.43: * new .base64 pseudo-op, allowing base64 encoded data as strings * Intel APX: add support for CFCMOV, CCMP, CTEST, zero-upper, NF (APX_F now fully supported) * x86 Intel syntax now warns about more mnemonic suffixes * macros and .irp/.irpc/.rept bodies can use \+ to get at number of times the macro/body was executed * aarch64: support 'armv9.5-a' for -march, add support for LUT and LUT2 * s390: base register operand in D(X,B) and D(L,B) can now be omitted (ala 'D(X,)'); warn when register type doesn't match operand type (use option 'warn-regtype-mismatch=[strict|relaxed|no]' to adjust) * riscv: support various extensions: Zacas, Zcmp, Zfbfmin, Zvfbfmin, Zvfbfwma, Smcsrind/Sscsrind, XCvMem, XCvBi, XCvElw, XSfCease, all at version 1.0; remove support for assembly of privileged spec 1.9.1 (linking support remains) * arm: remove support for some old co-processors: Maverick and FPA * mips: '--trap' now causes either trap or breakpoint instructions to be emitted as per current ISA, instead of always using trap insn and failing when current ISA was incompatible with that * LoongArch: accept .option pseudo-op for fine-grained control of assembly code options; add support for DT_RELR * readelf: now displays RELR relocations in full detail; add -j/--display-section to show just those section(s) content according to their type * objdump/readelf now dump also .eh_frame_hdr (when present) when dumping .eh_frame * gprofng: add event types for AMD Zen3/Zen4 and Intel Ice Lake processors; add minimal support for riscv * linker: - put .got and .got.plt into relro segment - add -z isa-level-report=[none|all|needed|used] to the x86 ELF linker to report needed and used x86-64 ISA levels - add --rosegment option which changes the -z separate-code option so that only one read-only segment is created (instead of two) - add --section-ordering-file &lt;FILE&gt; option to add extra mapping of input sections to output sections - add -plugin-save-temps to store plugin intermediate files permanently - Removed binutils-2.42.tar.bz2, binutils-2.42-branch.diff.gz. - Added binutils-2.43.tar.bz2, binutils-2.43-branch.diff.gz. - Removed upstream patch riscv-no-relax.patch. - Rebased ld-relro.diff and binutils-revert-rela.diff. - binutils-pr22868.diff: Remove obsolete patch - Undefine _FORTIFY_SOURCE when running checks - Allow to disable profiling - Use %patch -P N instead of deprecated %patchN. - riscv-no-relax.patch: RISC-V: Don't generate branch/jump relocation if symbol is local when no-relax - Add binutils-disable-code-arch-error.diff to demote an error about swapped .arch/.code directives to a warning. It happens in the wild. - Update to version 2.42: * Add support for many aarch64 extensions: SVE2.1, SME2.1, B16B16, RASv2, LSE128, GCS, CHK, SPECRES2, LRCPC3, THE, ITE, D128, XS and flags to enable them: '+fcma', '+jscvt', '+frintts', '+flagm2', '+rcpc2' and '+wfxt' * Add experimantal support for GAS to synthesize call-frame-info for some hand-written asm (--scfi=experimental) on x86-64. * Add support for more x86-64 extensions: APX: 32 GPRs, NDD, PUSH2/POP2, PUSHP/POPP; USER_MSR, AVX10.1, PBNDKB, SM4, SM3, SHA512, AVX-VNNI-INT16. * Add support for more RISC-V extensions: T-Head v2.3.0, CORE-V v1.0, SiFive VCIX v1.0. * BPF assembler: ';' separates statements now, and does not introduce line comments anymore (use '#' or '//' for this). * x86-64 ld: Add '-z mark-plt/-z nomark-plt' to mark PLT entries with dynamic tags. * risc-v ld: Add '--[no-]check-uleb128'. * New linker script directive: REVERSE, to be combined with SORT_BY_NAME or SORT_BY_INIT_PRIORITY, reverses the generated order. * New linker options --warn-execstack-objects (warn only about execstack when input object files request it), and --error-execstack plus - -error-rxw-segments to convert the existing warnings into errors. * objdump: Add -Z/--decompress to be used with -s/--full-contents to decompress section contents before displaying. * readelf: Add --extra-sym-info to be used with --symbols (currently prints section name of references section index). * objcopy: Add --set-section-flags for x86_64 to include SHF_X86_64_LARGE. * s390 disassembly: add target-specific disasm option 'insndesc', as in &quot;objdump -M insndesc&quot; to display an instruction description as comment along with the disassembly. - Add binutils-2.42-branch.diff.gz. - Rebased s390-biarch.diff. - Adjusted binutils-revert-hlasm-insns.diff, binutils-revert-plt32-in-branches.diff and binutils-revert-rela.diff for upstream changes. - Removed binutils-2.41-branch.diff.gz, binutils-2.41.tar.bz2, binutils-2.41-branch.diff.gz. - Removed binutils-use-less-memory.diff, binutils-old-makeinfo.diff and riscv-relro.patch (all upstreamed). - Removed add-ulp-section.diff, we use a different mechanism for live patching since a long time. - Add binutils-use-less-memory.diff to be a little nicer to 32bit userspace and huge links. [bsc#1216908] - riscv-relro.patch: RISC-V: Protect .got with relro - Add libzstd-devel to Requires of binutils-devel. (bsc#1215341) Package ca-certificates-mozilla was updated: - Updated to 2.68 state of Mozilla SSL root CAs (bsc#1227525) - Added: FIRMAPROFESIONAL CA ROOT-A WEB - Distrust: GLOBALTRUST 2020 - Updated to 2.66 state of Mozilla SSL root CAs (bsc#1220356) Added: - CommScope Public Trust ECC Root-01 - CommScope Public Trust ECC Root-02 - CommScope Public Trust RSA Root-01 - CommScope Public Trust RSA Root-02 - D-Trust SBR Root CA 1 2022 - D-Trust SBR Root CA 2 2022 - Telekom Security SMIME ECC Root 2021 - Telekom Security SMIME RSA Root 2023 - Telekom Security TLS ECC Root 2020 - Telekom Security TLS RSA Root 2023 - TrustAsia Global Root CA G3 - TrustAsia Global Root CA G4 Removed: - Autoridad de Certificacion Firmaprofesional CIF A62634068 - Chambers of Commerce Root - 2008 - Global Chambersign Root - 2008 - Security Communication Root CA - Symantec Class 1 Public Primary Certification Authority - G6 - Symantec Class 2 Public Primary Certification Authority - G6 - TrustCor ECA-1 - TrustCor RootCert CA-1 - TrustCor RootCert CA-2 - VeriSign Class 1 Public Primary Certification Authority - G3 - VeriSign Class 2 Public Primary Certification Authority - G3 - remove-trustcor.patch: removed, now upstream - do a versioned obsoletes of &quot;openssl-certs&quot;. Package cloud-regionsrv-client was updated: - Update to 10.3.4 + Modify the message when network access over a specific IP version does not work. This is an informational message and should not look like an error + Inform the user that LTSS registration takes a little longer + Add fix-for-sles12-no-trans_update.patch + SLE 12 family has no products with transactional-update we do not need to look for this condition - From 10.3.3 (bsc#1229472) + Handle changes in process structure to properly identify the running zypper parent process and only check for 1 PID - From 10.3.2 + Remove rgnsrv-clnt-fix-docker-setup.patch included upstream - From 10.3.1 (jsc#PCT-400) + Add support for LTSS registration + Add fix-for-sles12-disable-registry.patch ~ No container support in SLE 12 - Add rgnsrv-clnt-fix-docker-setup.patch (bsc#1229137) + The entry for the update infrastructure registry mirror was written incorrectly causing docker daemon startup to fail. - Update to version 10.3.0 (bsc#1227308, bsc#1222985) + Add support for sidecar registry Podman and rootless Docker support to set up the necessary configuration for the container engines to run as defined + Add running command as root through sudoers file - Update to version 10.2.0 (bsc#1223571, bsc#1224014, bsc#1224016) + In addition to logging, write message to stderr when registration fails + Detect transactional-update system with read only setup and use the transactional-update command to register + Handle operation in a different target root directory for credentials checking Package kernel-default was updated: - btrfs: sysfs: update fs features directory asynchronously (bsc#1226168). - commit 97cd90c - ima: Fix use-after-free on a dentry's dname.name (bsc#1227716 CVE-2024-39494). - commit 81484ec - ASoC: topology: Fix route memory corruption (CVE-2024-41069 bsc#1228644). - commit 586db1a - net: do not leave a dangling sk pointer, when socket creation fails (CVE-2024-40954 bsc#1227808) - commit 8f44f81 - check-for-config-changes: ignore also GCC_ASM_GOTO_OUTPUT_BROKEN Mainline commit f2f6a8e88717 (&quot;init/Kconfig: remove CONFIG_GCC_ASM_GOTO_OUTPUT_WORKAROUND&quot;) replaced GCC_ASM_GOTO_OUTPUT_WORKAROUND with GCC_ASM_GOTO_OUTPUT_BROKEN. Ignore both when checking config changes. - commit b60be3e - IB/core: Implement a limit on UMAD receive List (bsc#1228743 CVE-2024-42145) - commit 810053d - ptp: fix integer overflow in max_vclocks_store (bsc#1227829 CVE-2024-40994). - commit 205cc4c - filelock: Remove locks reliably when fcntl/close race is detected (CVE-2024-41012 bsc#1228247). - commit e2c5917 - Update patches.suse/KVM-Always-flush-async-PF-workqueue-when-vCPU-is-being-des.patch (bsc#1223635 (CVE-2024-26976) CVE-2024-26976). - Update patches.suse/jfs-xattr-fix-buffer-overflow-for-invalid-xattr.patch (bsc#1227383 CVE-2024-40902 bsc#1227764). - Update patches.suse/vfio-fsl-mc-Block-calling-interrupt-handler-without-trigge.patch (bsc#1222810 (CVE-2024-26814) CVE-2024-26814). - Update patches.suse/vfio-platform-Create-persistent-IRQ-handlers.patch (bsc#1222809 (CVE-2024-26813) CVE-2024-26813). - commit 39eeeb9 - Update patches.suse/SUNRPC-Fix-UAF-in-svc_tcp_listen_data_ready.patch (git-fixes CVE-2023-52885 bsc#1227750). - Update patches.suse/USB-core-Fix-race-by-not-overwriting-udev-descriptor.patch (bsc#1213123 CVE-2023-37453 CVE-2023-52886 bsc#1227981). - Update patches.suse/virtio-blk-fix-implicit-overflow-on-virtio_max_dma_size.patch (bsc#1225573 (CVE-2023-52762) CVE-2023-52762). - commit 3784f34 - Update patches.suse/HID-hid-thrustmaster-fix-OOB-read-in-thrustmaster_in.patch (git-fixes CVE-2022-48866 bsc#1228014). - Update patches.suse/Input-aiptek-properly-check-endpoint-type.patch (git-fixes CVE-2022-48836 bsc#1227989). - Update patches.suse/KVM-x86-nSVM-fix-potential-NULL-derefernce-on-nested.patch (git-fixes CVE-2022-48793 bsc#1228019). - Update patches.suse/NFC-port100-fix-use-after-free-in-port100_send_compl.patch (git-fixes CVE-2022-48857 bsc#1228005). - Update patches.suse/NFSD-Fix-NFSv3-SETATTR-CREATE-s-handling-of-large-fi.patch (git-fixes CVE-2022-48829 bsc#1228055). - Update patches.suse/NFSD-Fix-ia_size-underflow.patch (git-fixes CVE-2022-48828 bsc#1228054). - Update patches.suse/NFSD-Fix-the-behavior-of-READ-near-OFFSET_MAX.patch (bsc#1195957 CVE-2022-48827 bsc#1228037). - Update patches.suse/SUNRPC-lock-against-sock-changing-during-sysfs-read.patch (bsc#1194324 CVE-2022-48816 bsc#1228038). - Update patches.suse/can-isotp-fix-potential-CAN-frame-reception-race-in-.patch (git-fixes CVE-2022-48830 bsc#1227982). - Update patches.suse/cfg80211-fix-race-in-netlink-owner-interface-destruc.patch (git-fixes CVE-2022-48784 bsc#1227938). - Update patches.suse/dmaengine-ptdma-Fix-the-error-handling-path-in-pt_co.patch (git-fixes CVE-2022-48774 bsc#1227923). - Update patches.suse/drm-amdgpu-bypass-tiling-flag-check-in-virtual-displ.patch (git-fixes CVE-2022-48849 bsc#1228061). - Update patches.suse/drm-vc4-Fix-deadlock-on-DSI-device-attach-error.patch (git-fixes CVE-2022-48826 bsc#1227975). - Update patches.suse/drm-vrr-Set-VRR-capable-prop-only-if-it-is-attached-.patch (git-fixes CVE-2022-48843 bsc#1228066). - Update patches.suse/eeprom-ee1004-limit-i2c-reads-to-I2C_SMBUS_BLOCK_MAX.patch (git-fixes CVE-2022-48806 bsc#1227948). - Update patches.suse/ethernet-Fix-error-handling-in-xemaclite_of_probe.patch (git-fixes CVE-2022-48860 bsc#1228008). - Update patches.suse/fs-proc-task_mmu.c-don-t-read-mapcount-for-migration-entry.patch (CVE-2023-1582 bsc#1209636 CVE-2022-48802 bsc#1227942). - Update patches.suse/gianfar-ethtool-Fix-refcount-leak-in-gfar_get_ts_inf.patch (git-fixes CVE-2022-48856 bsc#1228004). - Update patches.suse/iavf-Fix-hang-during-reboot-shutdown.patch (jsc#SLE-18385 CVE-2022-48840 bsc#1227990). - Update patches.suse/ibmvnic-don-t-release-napi-in-__ibmvnic_open.patch (bsc#1195668 ltc#195811 CVE-2022-48811 bsc#1227928). - Update patches.suse/ice-Fix-KASAN-error-in-LAG-NETDEV_UNREGISTER-handler.patch (git-fixes CVE-2022-48807 bsc#1227970). - Update patches.suse/ice-Fix-race-condition-during-interface-enslave.patch (git-fixes CVE-2022-48842 bsc#1228064). - Update patches.suse/ice-fix-NULL-pointer-dereference-in-ice_update_vsi_t.patch (jsc#SLE-18375 CVE-2022-48841 bsc#1227991). - Update patches.suse/iio-buffer-Fix-file-related-error-handling-in-IIO_BU.patch (git-fixes CVE-2022-48801 bsc#1227956). - Update patches.suse/ima-fix-reference-leak-in-asymmetric_verify.patch (git-fixes CVE-2022-48831 bsc#1227986). - Update patches.suse/iommu-Fix-potential-use-after-free-during-probe (git-fixes CVE-2022-48796 bsc#1228028). - Update patches.suse/iwlwifi-fix-use-after-free.patch (bsc#1197762 git-fixes CVE-2022-48787 bsc#1227932). - Update patches.suse/mISDN-Fix-memory-leak-in-dsp_pipeline_build.patch (git-fixes CVE-2022-48863 bsc#1228063). - Update patches.suse/misc-fastrpc-avoid-double-fput-on-failed-usercopy.patch (git-fixes CVE-2022-48821 bsc#1227976). - Update patches.suse/mm-don-t-try-to-NUMA-migrate-COW-pages-that-have-other-uses.patch (git fixes (mm/numa) CVE-2022-48797 bsc#1228035). - Update patches.suse/mm-vmscan-remove-deadlock-due-to-throttling.patch (bsc#1195357 CVE-2022-48800 bsc#1227954). - Update patches.suse/msft-hv-2515-Drivers-hv-vmbus-Fix-memory-leak-in-vmbus_add_channe.patch (git-fixes CVE-2022-48775 bsc#1227924). - Update patches.suse/mtd-parsers-qcom-Fix-kernel-panic-on-skipped-partiti.patch (git-fixes CVE-2022-48777 bsc#1227922). - Update patches.suse/mtd-parsers-qcom-Fix-missing-free-for-pparts-in-clea.patch (git-fixes CVE-2022-48776 bsc#1227925). - Update patches.suse/mtd-rawnand-gpmi-don-t-leak-PM-reference-in-error-pa.patch (git-fixes CVE-2022-48778 bsc#1227935). - Update patches.suse/net-dsa-ar9331-register-the-mdiobus-under-devres.patch (git-fixes CVE-2022-48817 bsc#1227931). - Update patches.suse/net-dsa-bcm_sf2-don-t-use-devres-for-mdiobus.patch (git-fixes CVE-2022-48815 bsc#1227933). - Update patches.suse/net-dsa-felix-don-t-use-devres-for-mdiobus.patch (git-fixes CVE-2022-48813 bsc#1227963). - Update patches.suse/net-dsa-lantiq_gswip-don-t-use-devres-for-mdiobus.patch (git-fixes CVE-2022-48812 bsc#1227971). - Update patches.suse/net-dsa-lantiq_gswip-fix-use-after-free-in-gswip_rem.patch (git-fixes CVE-2022-48783 bsc#1227949). - Update patches.suse/net-dsa-mv88e6xxx-don-t-use-devres-for-mdiobus.patch (git-fixes CVE-2022-48818 bsc#1228039). - Update patches.suse/net-dsa-seville-register-the-mdiobus-under-devres.patch (git-fixes CVE-2022-48814 bsc#1227944). - Update patches.suse/net-ieee802154-at86rf230-Stop-leaking-skb-s.patch (git-fixes CVE-2022-48794 bsc#1228025). - Update patches.suse/net-marvell-prestera-Add-missing-of_node_put-in-pres.patch (git-fixes CVE-2022-48859 bsc#1228007). - Update patches.suse/net-mlx5-Fix-a-race-on-command-flush-flow.patch (git-fixes CVE-2022-48858 bsc#1228006). - Update patches.suse/net-packet-fix-slab-out-of-bounds-access-in-packet_r.patch (CVE-2022-20368 bsc#1202346 CVE-2022-48839 bsc#1227985). - Update patches.suse/net-smc-Avoid-overwriting-the-copies-of-clcsock-callback-functions (git-fixes CVE-2022-48780 bsc#1227995). - Update patches.suse/net-usb-ax88179_178a-Fix-out-of-bounds-accesses-in-R.patch (bsc#1196018 CVE-2022-28748 bsc#1202686 CVE-2022-2964 CVE-2022-48805 bsc#1227969). - Update patches.suse/nvme-fix-a-possible-use-after-free-in-controller-res.patch (bsc#1193787 bsc#1197146 bsc#1193554 CVE-2022-48790 bsc#1227941). - Update patches.suse/nvme-rdma-fix-possible-use-after-free-in-transport-e.patch (bsc#1193787 bsc#1197146 bsc#1193554 CVE-2022-48788 bsc#1227952). - Update patches.suse/nvme-tcp-fix-possible-use-after-free-in-transport-er.patch (bsc#1193787 bsc#1197146 bsc#1193554 CVE-2022-48789 bsc#1228000). - Update patches.suse/perf-Fix-list-corruption-in-perf_cgroup_switch.patch (git fixes CVE-2022-48799 bsc#1227953). - Update patches.suse/phy-stm32-fix-a-refcount-leak-in-stm32_usbphyc_pll_e.patch (git-fixes CVE-2022-48820 bsc#1227972). - Update patches.suse/phy-ti-Fix-missing-sentinel-for-clk_div_table.patch (git-fixes CVE-2022-48803 bsc#1227965). - Update patches.suse/s390-cio-verify-the-driver-availability-for-path_event-call (bsc#1195927 LTC#196420 CVE-2022-48798 bsc#1227945). - Update patches.suse/scsi-mpt3sas-Page-fault-in-reply-q-processing.patch (git-fixes CVE-2022-48835 bsc#1228060). - Update patches.suse/scsi-myrs-Fix-crash-in-error-case.patch (git-fixes CVE-2022-48824 bsc#1227964). - Update patches.suse/scsi-pm8001-Fix-use-after-free-for-aborted-SSP-STP-sas_task.patch (git-fixes CVE-2022-48792 bsc#1228013). - Update patches.suse/scsi-pm8001-Fix-use-after-free-for-aborted-TMF-sas_task.patch (git-fixes CVE-2022-48791 bsc#1228002). - Update patches.suse/scsi-qedf-Add-stag_work-to-all-the-vports.patch (git-fixes CVE-2022-48825 bsc#1228056). - Update patches.suse/scsi-qedf-Fix-refcount-issue-when-LOGO-is-received-during-TMF.patch (git-fixes CVE-2022-48823 bsc#1228045). - Update patches.suse/staging-gdm724x-fix-use-after-free-in-gdm_lte_rx.patch (git-fixes CVE-2022-48851 bsc#1227997). - Update patches.suse/swiotlb-fix-info-leak-with-DMA_FROM_DEVICE.patch (CVE-2022-0854 bsc#1196823 CVE-2022-48853 bsc#1228015). - Update patches.suse/usb-f_fs-Fix-use-after-free-for-epfile.patch (git-fixes CVE-2022-48822 bsc#1228040). - Update patches.suse/usb-gadget-Fix-use-after-free-bug-by-not-setting-udc.patch (git-fixes CVE-2022-48838 bsc#1227988). - Update patches.suse/usb-gadget-rndis-prevent-integer-overflow-in-rndis_s.patch (git-fixes CVE-2022-48837 bsc#1227987). - Update patches.suse/usb-usbtmc-Fix-bug-in-pipe-direction-for-control-tra.patch (git-fixes CVE-2022-48834 bsc#1228062). - Update patches.suse/vdpa-fix-use-after-free-on-vp_vdpa_remove.patch (git-fixes CVE-2022-48861 bsc#1228009). - Update patches.suse/vhost-fix-hung-thread-due-to-erroneous-iotlb-entries.patch (git-fixes CVE-2022-48862 bsc#1228010). - Update patches.suse/vsock-remove-vsock-from-connected-table-when-connect.patch (git-fixes CVE-2022-48786 bsc#1227996). - Update patches.suse/vt_ioctl-fix-array_index_nospec-in-vt_setactivate.patch (git-fixes CVE-2022-48804 bsc#1227968). - Update patches.suse/watch_queue-Fix-filter-limit-check.patch (CVE-2022-0995 bsc#1197246 CVE-2022-48847 bsc#1227993). - Update patches.suse/xprtrdma-fix-pointer-derefs-in-error-cases-of-rpcrdm.patch (git-fixes CVE-2022-48773 bsc#1227921). - commit e328ee7 - Update patches.suse/net-sunrpc-fix-reference-count-leaks-in-rpc_sysfs_xp.patch (git-fixes CVE-2021-47624 bsc#1227920). - Update patches.suse/scsi-ufs-Fix-a-deadlock-in-the-error-handler.patch (git-fixes CVE-2021-47622 bsc#1227917). - commit f2d923e - cgroup/cpuset: Prevent UAF in proc_cpuset_show() (bsc#1228801). - commit 8837200 - net/dpaa2: Avoid explicit cpumask var allocation on stack (CVE-2024-42093 bsc#1228680). - commit e2a1614 - workqueue: Improve scalability of workqueue watchdog touch (bsc#1193454). - commit 51a7eb4 - workqueue: wq_watchdog_touch is always called with valid CPU (bsc#1193454). - commit 10bbd80 - KVM: arm64: Disassociate vcpus from redistributor region on teardown (CVE-2024-40989 bsc#1227823). - commit 724dd5c - ASoC: topology: Fix references to freed memory (CVE-2024-41069 bsc#1228644). - commit 44dd0c7 - Update patches.suse/ext2-Avoid-reading-renamed-directory-if-parent-does-.patch (bsc#1221044 CVE-2023-52591 bsc#1228440). - commit d21f810 - hfsplus: fix uninit-value in copy_name (bsc#1228561 CVE-2024-41059). - commit cfc2db1 - dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list (CVE-2024-40956 bsc#1227810). - commit 3632d87 - ocfs2: fix DIO failure due to insufficient transaction credits (bsc#1216834). - commit edabc6f - tap: add missing verification for short frame (CVE-2024-41090 bsc#1228328). - commit e64bcfc - rpm/guards: fix precedence issue with control flow operator With perl 5.40 it report the following error on rpm/guards script: Possible precedence issue with control flow operator (exit) at scripts/guards line 208. Fix the issue by adding parenthesis around ternary operator. - commit 07b8b4e - drm/amdkfd: don't allow mapping the MMIO HDP page with large pages (CVE-2024-41011 bsc#1228115). - commit ff8f843 - 9p: add missing locking around taking dentry fid list (bsc#1227090, CVE-2024-39463). - commit c58a66f - sch_cake: do not call cake_destroy() from cake_init() (CVE-2021-47598 bsc#1226574). - commit d533b8e - gve: Clear napi-&gt;skb before dev_kfree_skb_any() (CVE-2024-40937 bsc#1227836). - commit 610d469 - Update patches.suse/powerpc-pseries-iommu-LPAR-panics-during-boot-up-wit.patch (bsc#1222011 ltc#205900 CVE-2024-36926 bsc#1225829). - commit 1ec0d1e - Update patches.suse/perf-x86-intel-pt-Fix-crash-with-stop-filters-in-single-range-mode.patch (git fixes CVE-2022-48713 bsc#1227549). - Update patches.suse/scsi-qedf-Ensure-the-copied-buf-is-NUL-terminated.patch (bsc#1226758 CVE-2024-38559 bsc#1226785). - Update patches.suse/tls-fix-use-after-free-on-failed-backlog-decryption.patch (CVE-2024-26583 CVE-2024-26584 bsc#1220185 bsc#1220186 CVE-2024-26800 bsc#1222728). - commit 329a684 - vfio/fsl-mc: Block calling interrupt handler without trigger (bsc#1222810 CVE-2024-26814). - commit 520ae3c - KVM: Always flush async #PF workqueue when vCPU is being destroyed (bsc#1223635 CVE-2024-26976). - commit c5ed396 - virtio-blk: fix implicit overflow on virtio_max_dma_size (bsc#1225573 CVE-2023-52762). - commit 4296dc1 - vfio/platform: Create persistent IRQ handlers (bsc#1222809 CVE-2024-26813). - commit a8290e8 - net: mana: Fix Rx DMA datasize and skb_over_panic (git-fixes CVE-2024-35901 bsc#1224495). - commit 9db7ad0 - Update patches.suse/net-tls-factor-out-tls_-crypt_async_wait.patch. - fix build warning - commit 01715f7 - powerpc/pseries: Fix scv instruction crash with kexec (bsc#1194869 CVE-2024-42230). - powerpc/kasan: Disable address sanitization in kexec paths (bsc#1194869 CVE-2024-42230). - commit c9d175f - kernel-binary: vdso: Own module_dir - commit ff69986 - Update patches.suse/scsi-qedf-Ensure-the-copied-buf-is-NUL-terminated.patch (bsc#1226785 CVE-2024-38559). Fixed incorrect bug reference. - commit e3b8fb6 - net/dcb: check for detached device before executing callbacks (bsc#1215587). - commit 9c27e1c - kABI: rtas: Workaround false positive due to lost definition (bsc#1227487). - commit fb8a8f3 - powerpc/rtas: Prevent Spectre v1 gadget construction in sys_rtas() (bsc#1227487). - commit 9648fb4 - tls: fix use-after-free on failed backlog decryption (CVE-2024-26583 CVE-2024-26584 bsc#1220185 bsc#1220186). - tls: separate no-async decryption request handling from async (CVE-2024-26583 CVE-2024-26584 bsc#1220185 bsc#1220186). - tls: decrement decrypt_pending if no async completion will be called (CVE-2024-26583 CVE-2024-26584 bsc#1220185 bsc#1220186). - net: tls: handle backlogging of crypto requests (CVE-2024-26584 bsc#1220186). - tls: fix race between tx work scheduling and socket close (CVE-2024-26585 bsc#1220187). - tls: fix race between async notify and socket close (CVE-2024-26583 bsc#1220185). - net: tls: factor out tls_*crypt_async_wait() (CVE-2024-26583 CVE-2024-26584 bsc#1220185 bsc#1220186). - net: tls: fix async vs NIC crypto offload (CVE-2024-26583 CVE-2024-26584 bsc#1220185 bsc#1220186). - tls: rx: use async as an in-out argument (CVE-2024-26583 CVE-2024-26584 bsc#1220185 bsc#1220186). - tls: rx: assume crypto always calls our callback (CVE-2024-26583 CVE-2024-26584 bsc#1220185 bsc#1220186). - tls: rx: don't track the async count (CVE-2024-26583 CVE-2024-26584 bsc#1220185 bsc#1220186). - tls: rx: simplify async wait (CVE-2024-26583 CVE-2024-26584 bsc#1220185 bsc#1220186). - tls: rx: wrap decryption arguments in a structure (CVE-2024-26583 CVE-2024-26584 bsc#1220185 bsc#1220186). - tls: rx: don't report text length from the bowels of decrypt (CVE-2024-26583 CVE-2024-26584 bsc#1220185 bsc#1220186). - tls: rx: drop unnecessary arguments from tls_setup_from_iter() (CVE-2024-26583 CVE-2024-26584 bsc#1220185 bsc#1220186). - commit 63dd4a4 - Delete patches.suse/tls-fix-race-between-tx-work-scheduling-and-socket-c.patch. Will be replaced with a refreshed version once all conflicting new patches are in. - commit a0fa0a3 - NFS: Reduce use of uncached readdir (bsc#1226662). - NFS: Don't re-read the entire page cache to find the next cookie (bsc#1226662). - commit a10cc0e - jfs: xattr: fix buffer overflow for invalid xattr (bsc#1227383). - commit 33e2d96 Package containerd was updated: - Update to containerd v1.7.21. Upstream release notes: &lt;https://github.com/containerd/containerd/releases/tag/v1.7.21&gt; Fixes CVE-2023-47108. bsc#1217070 Fixes CVE-2023-45142. bsc#1228553 - Rebase patches: * 0001-BUILD-SLE12-revert-btrfs-depend-on-kernel-UAPI-inste.patch Package cups was updated: - cups-branch-2.2-commit-b643d6ba92f00752aa5e74ff86ad3974334914c1.diff is https://github.com/OpenPrinting/cups/commit/b643d6ba92f00752aa5e74ff86ad3974334914c1 which was added in CUPS 2.2.8 that fixed a parsing bug in cups_auth_find() in cups/auth.c which lead to cupsd failing to authenticate users when group membership is required by cupsd configuration like 'Require user @GROUP' which lead to CUPS related commands requesting password from group users even if it is not needed (bsc#1226227) - In cups.changes replaced one place where UTF-8 characters were used in the entry dated &quot;Sat Sep 30 08:52:42 UTC 2017&quot; for what should be ' - ' by ASCII to avoid RPMLINT warning about 'non-break-space' which &quot;can lead to obscure errors&quot;. Package curl was updated: - Security fix: [bsc#1230093, CVE-2024-8096] * curl: OCSP stapling bypass with GnuTLS * Add curl-CVE-2024-8096.patch - Security fix: [bsc#1228535, CVE-2024-7264] * curl: ASN.1 date parser overread * Add curl-CVE-2024-7264.patch Package deltarpm was updated: - update to deltarpm-3.6.4 * support for threaded zstd * use a tmp file instead of memory to hold the incore data [bsc#1228948] - dropped patches: * deltarpm-b7987f6aa4211df3df03dcfc55a00b2ce7472e0a.patch - deltarpm-b7987f6aa4211df3df03dcfc55a00b2ce7472e0a.patch: fixed some C bugs ( incorrect sized memset() , memcpy instead of strcpy, unsigned int) - update to deltarpm-3.6.3 * support for threaded zstd compression - Actually enable zstd compression - update to deltarpm-3.6.2 * support for zstd compression Package dmidecode was updated: - Update to upstream version 3.6 (jsc#PED-8574): * Support for SMBIOS 3.6.0. This includes new memory device types, new processor upgrades, and Loongarch support. * Support for SMBIOS 3.7.0. This includes new port types, new processor upgrades, new slot characteristics and new fields for memory modules. * Add bash completion. * Decode HPE OEM records 197, 216, 224, 230, 238, 239, 242 and 245. * Implement options --list-strings and --list-types. * Update HPE OEM records 203, 212, 216, 221, 233 and 236. * Update Redfish support. * Bug fixes: Fix enabled slot characteristics not being printed * Minor improvements: Print slot width on its own line Use standard strings for slot width * Add a --no-quirks option. * Drop the CPUID exception list. * Obsoletes dmidecode-do-not-let-dump-bin-overwrite-an-existing-file.patch, dmidecode-fortify-entry-point-length-checks.patch, dmidecode-split-table-fetching-from-decoding.patch, dmidecode-write-the-whole-dump-file-at-once.patch, dmioem-fix-segmentation-fault-in-dmi_hp_240_attr.patch, dmioem-hpe-oem-record-237-firmware-change.patch, dmioem-typo-fix-virutal-virtual.patch, ensure-dev-mem-is-a-character-device-file.patch, news-fix-typo.patch and use-read_file-to-read-from-dump.patch. Update for HPE servers from upstream: - dmioem-update-hpe-oem-type-238.patch: Decode PCI bus segment in HPE type 238 records. Package dracut was updated: - Update to version 055+suse.359.geb85610b: * fix(convertfs): error in conditional expressions (bsc#1228847) Package expat was updated: - Security fix (bsc#1229932, CVE-2024-45492): detect integer overflow in function nextScaffoldPart * Added expat-CVE-2024-45492.patch - Security fix (bsc#1229931, CVE-2024-45491): detect integer overflow in dtdCopy * Added expat-CVE-2024-45491.patch - Security fix (bsc#1229930, CVE-2024-45490): reject negative len for XML_ParseBuffer * Added expat-CVE-2024-45490.patch Package glib2 was updated: - Add glib2-gdbusmessage-cache-arg0.patch: cache the arg0 value in a dbus message. Fixes a possible use after free (boo#1224044). Package glibc was updated: - s390x-wcsncmp.patch: s390x: Fix segfault in wcsncmp (bsc#1228043, BZ [#31934]) Package grub2 was updated: - Fix btrfs subvolume for platform modules not mounting at runtime when the default subvolume is the topmost root tree (bsc#1228124) * grub2-btrfs-06-subvol-mount.patch - Rediff * 0001-Unify-the-check-to-enable-btrfs-relative-path.patch - Fix error in grub-install when root is on tmpfs (bsc#1226100) * 0001-grub-install-bailout-root-device-probing.patch - Fix input handling in ppc64le grub2 has high latency (bsc#1223535) * 0001-net-drivers-ieee1275-ofnet-Remove-200-ms-timeout-in-.patch - Fix PowerPC grub loads 5 to 10 minutes slower on SLE-15-SP5 compared to SLE-15-SP2 (bsc#1217102) * add 0001-ofdisk-enhance-boot-time-by-focusing-on-boot-disk-re.patch * add 0002-ofdisk-add-early_log-support.patch - Enhancement to PPC secure boot's root device discovery config (bsc#1207230) - Fix regex for Open Firmware device specifier with encoded commas * 0002-prep_loadenv-Fix-regex-for-Open-Firmware-device-spec.patch - Fix regular expression in PPC secure boot config to prevent escaped commas from being treated as delimiters when retrieving partition substrings. - Use prep_load_env in PPC secure boot config to handle unset host-specific environment variables and ensure successful command execution. * 0004-Introduce-prep_load_env-command.patch - Refreshed * 0005-export-environment-at-start-up.patch Package libqt5-qtbase was updated: - Added a patch from upstream to prepare the code so that the following patch can be applied (which fixes QTBUG-95277): * 0001-H2-emit-encrypted-for-at-least-the-first-reply_-similar-to.patch - Add rebased upstream patch to delay any HTTP2 communication until encrypted() can be responded to (bsc#1227426, CVE-2024-39936). * 0001-HTTP2-Delay-any-communication-until-encrypted-can-be.patch - Add upstream patch to fix a NULL pointer dereference via the function QXcbConnection::initializeAllAtoms() when there is anomalous behavior from the X server (bsc#1222120, CVE-2023-45935): * 0001-xcb-guard-a-pointer-before-usage.patch - Add patch from upstream to fix a regression in the ODBC driver (bsc#1227513, QTBUG-112375): * 0001-QSQL-ODBC-fix-regression-trailing-NUL.patch * 0002-SQL-ODBC-Pass-correct-length-to-SQLColAttribute.patch - Add upstream patches to fix an incorrect integer overflow check (boo#1218413, CVE-2023-51714): * 0001-HPack-fix-a-Yoda-Condition.patch * 0002-HPack-fix-incorrect-integer-overflow-check.patch - Add upstream patch to fix a potential overflow in assemble_hpack_block(): * 0001-Http2-fix-potential-overflow-in-assemble_hpack_block.patch Package util-linux was updated: - agetty: Prevent login cursor escape (bsc#1194818, util-linux-agetty-prevent-cursor-escape.patch). Package mozilla-nss was updated: - Updated nss-fips-approved-crypto-non-ec.patch to enforce approved curves with the CKK_EC_MONTGOMERY key type (bsc#1224113). Package openssl-1_1 was updated: - Build with no-afalgeng [bsc#1226463] - Security fix: [bsc#1227138, CVE-2024-5535] * SSL_select_next_proto buffer overread * Add openssl-CVE-2024-5535.patch Package libpcap was updated: - Security fix: [bsc#1230034, CVE-2024-8006] * libpcap: NULL pointer derefence in pcap_findalldevs_ex() * Add libpcap-CVE-2024-8006.patch - Security fix: [bsc#1230020, CVE-2023-7256] * libpcap: double free via addrinfo in sock_initaddress() * Add libpcap-CVE-2023-7256.patch Package libsolv was updated: - removed dependency on external find program in the repo2solv tool- bindings: fix return value of repodata.add_solv() - new SOLVER_FLAG_FOCUS_NEW flag - bump version to 0.7.30 Package systemd was updated: - Import commit a57a6d239c5d6b91fb3dcd269705e60804a03ae1 cd0c9ac4f4 unit: drop ProtectClock=yes from systemd-udevd.service (bsc#1226414) e1eaa86a49 udev: do not set ID_PATH and by-path symlink for nvmf disks a85d211874 man: Document ranges for distributions config files and local config files - Don't mention any rpm macros inside comments, even if escaped (bsc#1228091) Otherwise pesign-obs-integration ends up re-packaging systemd with all macros inside comments unescaped leading to unpredictable behavior. Now why rpm expands rpm macros inside comments is the question... - Update 1011-sysv-generator-add-back-support-for-SysV-scripts-for.patch Really skip redundant dependencies specified the LSB description that references the file name of the service itself for early boot scripts (noticed in bsc#1221479). Package tiff was updated: - security update: * CVE-2024-7006 [bsc#1228924] Fix pointer deref in tif_dirinfo.c + tiff-CVE-2024-7006.patch Package libzypp was updated: - Make sure not to statically linked installed tools (bsc#1228787)- version 17.35.8 (35) - MediaPluginType must be resolved to a valid MediaHandler (bsc#1228208) - version 17.35.7 (35) - Export CredentialManager for legacy YAST versions (bsc#1228420) - version 17.35.6 (35) - Export asSolvable for YAST (bsc#1228420) - Fix 4 typos in zypp.conf. - version 17.35.5 (35) - Fix typo in the geoip update pipeline (bsc#1228206) - Export RepoVariablesStringReplacer for yast2 (bsc#1228138) - version 17.35.4 (35) - Translation: updated .pot file. - Conflict with python zypp-plugin &lt; 0.6.4 (bsc#1227793) Older zypp-plugins reject stomp headers including a '-'. Like the 'content-length' header we may send. - Fix int overflow in Provider (fixes #559) This patch fixes an issue in safe_strtonum which caused timestamps to overflow in the Provider message parser. - Fix error reporting on repoindex.xml parse error (bsc#1227625) - version 17.35.3 (35) - Keep UrlResolverPlugin API public (fixes #560) - Blacklist /snap executables for 'zypper ps' (bsc#1226014) - Fix handling of buddies when applying locks (bsc#1225267) Buddy pairs (like -release package and product) internally share the same status object. When applying locks from query results the locked bit must be set if either item is locked. - version 17.35.2 (35) - Install zypp/APIConfig.h legacy include (fixes #557) - version 17.35.1 (35) - Update soname due to RepoManager refactoring and cleanup. - version 17.35.0 (35) - Workaround broken libsolv-tools-base requirements (fixes openSUSE/zypper#551) - Strip ssl_clientkey from repo urls (bsc#1226030) - Remove protobuf build dependency. - Lazily attach medium during refresh workflows (bsc#1223094) - Refactor RepoManager and add Service workflows. - version 17.34.2 (34) Package pam was updated: - Prevent cursor escape from the login prompt [bsc#1194818] * Added: pam-bsc1194818-cursor-escape.patch Package python-PyYAML was updated: Package python3-setuptools was updated: - Add patch CVE-2024-6345-code-execution-via-download-funcs.patch: * Sanitize any VCS URL we download. (CVE-2024-6345, bsc#1228105) Package zypp-plugin was updated: - Fix stomp header regex to include '-' (bsc#1227793)- version 0.6.4 - singlespec in Tumbleweed must support multiple python3 flavors in the future gh#openSUSE/python-rpm-macros#66 - Provide python3-zypp-plugin down to SLE12 (bsc#1081596) - Provide python3-zypp-plugin in SLE12-SP3 (bsc#1081596) Package regionServiceClientConfigGCE was updated: - Version 4.2.0 (jsc#PCT-361) + Add IPv6 certs to supprt access of the update infrastructure via IPv6 on GCE instances. - Update to version 4.1.0 (bsc#1217538) + Replace 162.222.182.90 and 35.187.193.56 (length 4096): rgnsrv-gce-asia-northeast1 -&gt; 162.222.182.90 expires in 9 years rgnsrv-gce-us-central1 -&gt; 35.187.193.56 expires in 10 years Package runc was updated: [ This was only ever released for SLES and Leap. ]- Update to runc v1.1.14. Upstream changelog is available from &lt;https://github.com/opencontainers/runc/releases/tag/v1.1.14&gt;. Includes the patch for CVE-2024-45310. bsc#1230092 - Rebase patches: * 0001-bsc1221050-libct-seccomp-patchbpf-rm-duplicated-code.patch * 0002-bsc1221050-seccomp-patchbpf-rename-nativeArch-linuxA.patch * 0003-bsc1221050-seccomp-patchbpf-always-include-native-ar.patch * 0004-bsc1214960-nsenter-cloned_binary-remove-bindfd-logic.patch Package saptune was updated: - update package version of saptune to 3.1.3 * remove note 1868829 from solution S4HANA-APPSERVER as it is a HANA DB note and was added by accident (bsc#1226093) * for verify and simulate output table - wrap content of the columns 'actual', 'expected' and 'override', if they exceed a width of 30 characters (e.g. net.ipv4.ip_local_reserved_ports) * support inline comments in /etc/sysconfig/saptune * change handling of the performance options. Check, if the settings are supported in the get-Functions too. This should fix the problem with some special Azure VMs (E20d_v5) on newer SLES SPs (jsc#SAPSOL-110) * SAP Note 2578899 updated to Version 48 setting kernel.pid_max to 4194304 and start sysctl-logger service 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 supportutils was updated: - Changes to version 3.2.8 + Avoid getting duplicate kernel verifications in boot.text (pr#190) + lvm: suppress file descriptor leak warnings from lvm commands (pr#191) + docker_info: Add timestamps to container logs (pr#196) + Key value pairs and container log timestamps (bsc#1222021 PED-8211, pr#198) + Update supportconfig get pam.d sorted (pr#199) + yast_files: Exclude .zcat (pr#201) + Sanitize grub bootloader (bsc#1227127, pr#203) + Sanitize regcodes (pr#204) + Improve product detection (pr#205) + Add read_values for s390x (bsc#1228265, pr#206) + hardware_info: Remove old alsa ver check (pr#209) + drbd_info: Fix incorrect escape of quotes (pr#210) Package suse-build-key was updated: - extended 2048 bit SUSE SLE 12, 15 GA-SP5 key until 2028. (bsc#1229339) - gpg-pubkey-39db7c82-5f68629b.asc + gpg-pubkey-39db7c82-66c5d91a.asc Package unzip was updated: - Use %patch -P N instead of deprecated %patchN. - Build unzip-rcc using multibuild and update unzip-rcc.spec file Package util-linux-systemd was updated: - agetty: Prevent login cursor escape (bsc#1194818, util-linux-agetty-prevent-cursor-escape.patch). Package zypper was updated: - Show rpm install size before installing (bsc#1224771) If filesystem snapshots are taken before the installation (e.g. by snapper) no disk space is freed by removing old packages. In this case the install size of all packages is a hint how much additional disk space is needed by the new packages static content. - version 1.14.76 - Fix readline setup to handle Ctrl-C and Ctrl-D corrrectly (bsc#1227205) - version 1.14.75 - Let_readline_abort_on_Ctrl-C (bsc#1226493) - packages: add '--system' to show @System packages (bsc#222971) - version 1.14.74 The CVRF data is provided by SUSE under the Creative Commons License 4.0 with Attribution (CC-BY-4.0). https://publiccloudimagechangeinfo.suse.com/google/sles-15-sp4-sap-byos-v20240913-x86-64/ Public Cloud Image Info https://www.suse.com/support/security/rating/ SUSE Security Ratings Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 bind-utils-9.16.50-150400.5.43.1 binutils-2.43-150100.7.49.1 ca-certificates-mozilla-2.68-150200.33.1 cloud-regionsrv-client-10.3.4-150300.13.9.1 cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.9.1 cluster-md-kmp-default-5.14.21-150400.24.128.1 containerd-1.7.21-150000.117.1 cups-config-2.2.7-150000.3.65.1 curl-8.0.1-150400.5.50.1 deltarpm-3.6.4-150000.5.3.2 dlm-kmp-default-5.14.21-150400.24.128.1 dmidecode-3.6-150400.16.11.2 docker-25.0.6_ce-150000.207.1 dracut-055+suse.359.geb85610b-150400.3.37.2 expat-2.4.4-150400.3.22.1 gfs2-kmp-default-5.14.21-150400.24.128.1 glib2-tools-2.70.5-150400.3.14.1 glibc-2.31-150300.86.3 glibc-32bit-2.31-150300.86.3 glibc-i18ndata-2.31-150300.86.3 glibc-locale-2.31-150300.86.3 glibc-locale-base-2.31-150300.86.3 grub2-2.06-150400.11.46.1 grub2-i386-pc-2.06-150400.11.46.1 grub2-x86_64-efi-2.06-150400.11.46.1 kernel-default-5.14.21-150400.24.128.1 libQt5Core5-5.15.2+kde294-150400.6.15.1 libQt5DBus5-5.15.2+kde294-150400.6.15.1 libQt5Gui5-5.15.2+kde294-150400.6.15.1 libQt5Network5-5.15.2+kde294-150400.6.15.1 libQt5Widgets5-5.15.2+kde294-150400.6.15.1 libblkid1-2.37.2-150400.8.32.2 libctf-nobfd0-2.43-150100.7.49.1 libctf0-2.43-150100.7.49.1 libcups2-2.2.7-150000.3.65.1 libcurl4-8.0.1-150400.5.50.1 libexpat1-2.4.4-150400.3.22.1 libfdisk1-2.37.2-150400.8.32.2 libfreebl3-3.101.2-150400.3.51.1 libgio-2_0-0-2.70.5-150400.3.14.1 libglib-2_0-0-2.70.5-150400.3.14.1 libgmodule-2_0-0-2.70.5-150400.3.14.1 libgobject-2_0-0-2.70.5-150400.3.14.1 libgthread-2_0-0-2.70.5-150400.3.14.1 libmount1-2.37.2-150400.8.32.2 libopenssl1_1-1.1.1l-150400.7.72.1 libpcap1-1.10.1-150400.3.3.2 libsmartcols1-2.37.2-150400.8.32.2 libsoftokn3-3.101.2-150400.3.51.1 libsolv-tools-0.7.30-150400.3.27.2 libsolv-tools-base-0.7.30-150400.3.27.2 libsystemd0-249.17-150400.8.43.1 libtiff5-4.0.9-150000.45.47.1 libudev1-249.17-150400.8.43.1 libuuid1-2.37.2-150400.8.32.2 libwebp7-1.0.3-150200.3.12.1 libyaml-0-2-0.1.7-150000.3.2.1 libyui-ncurses-pkg16-4.3.7-150400.3.12.1 libyui-ncurses16-4.3.7-150400.3.12.1 libyui-qt16-4.3.7-150400.3.12.1 libyui16-4.3.7-150400.3.12.1 libzypp-17.35.8-150400.3.85.1 mozilla-nss-3.101.2-150400.3.51.1 mozilla-nss-certs-3.101.2-150400.3.51.1 mozilla-nss-tools-3.101.2-150400.3.51.1 nscd-2.31-150300.86.3 ocfs2-kmp-default-5.14.21-150400.24.128.1 openssl-1_1-1.1.1l-150400.7.72.1 pam-1.3.0-150000.6.71.2 python3-PyYAML-5.4.1-150300.3.3.1 python3-bind-9.16.50-150400.5.43.1 python3-setuptools-44.1.1-150400.9.9.1 python3-solv-0.7.30-150400.3.27.2 python3-zypp-plugin-0.6.4-150400.13.4.1 regionServiceClientConfigGCE-4.2.0-150000.4.15.1 ruby-solv-0.7.30-150400.3.27.2 runc-1.1.14-150000.70.1 saptune-3.1.3-150400.15.9.1 supportutils-3.2.8-150300.7.35.33.1 suse-build-key-12.0-150000.8.52.3 systemd-249.17-150400.8.43.1 systemd-sysvinit-249.17-150400.8.43.1 udev-249.17-150400.8.43.1 unzip-6.00-150000.4.14.1 util-linux-2.37.2-150400.8.32.2 util-linux-systemd-2.37.2-150400.8.32.2 uuidd-2.37.2-150400.8.32.2 yast2-pkg-bindings-4.4.7-150400.3.16.1 zypper-1.14.76-150400.3.57.16 bind-utils-9.16.50-150400.5.43.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 binutils-2.43-150100.7.49.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 ca-certificates-mozilla-2.68-150200.33.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 cloud-regionsrv-client-10.3.4-150300.13.9.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.9.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 cluster-md-kmp-default-5.14.21-150400.24.128.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 containerd-1.7.21-150000.117.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 cups-config-2.2.7-150000.3.65.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 curl-8.0.1-150400.5.50.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 deltarpm-3.6.4-150000.5.3.2 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 dlm-kmp-default-5.14.21-150400.24.128.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 dmidecode-3.6-150400.16.11.2 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 docker-25.0.6_ce-150000.207.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 dracut-055+suse.359.geb85610b-150400.3.37.2 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 expat-2.4.4-150400.3.22.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 gfs2-kmp-default-5.14.21-150400.24.128.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 glib2-tools-2.70.5-150400.3.14.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 glibc-2.31-150300.86.3 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 glibc-32bit-2.31-150300.86.3 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 glibc-i18ndata-2.31-150300.86.3 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 glibc-locale-2.31-150300.86.3 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 glibc-locale-base-2.31-150300.86.3 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 grub2-2.06-150400.11.46.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 grub2-i386-pc-2.06-150400.11.46.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 grub2-x86_64-efi-2.06-150400.11.46.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 kernel-default-5.14.21-150400.24.128.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libQt5Core5-5.15.2+kde294-150400.6.15.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libQt5DBus5-5.15.2+kde294-150400.6.15.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libQt5Gui5-5.15.2+kde294-150400.6.15.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libQt5Network5-5.15.2+kde294-150400.6.15.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libQt5Widgets5-5.15.2+kde294-150400.6.15.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libblkid1-2.37.2-150400.8.32.2 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libctf-nobfd0-2.43-150100.7.49.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libctf0-2.43-150100.7.49.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libcups2-2.2.7-150000.3.65.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libcurl4-8.0.1-150400.5.50.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libexpat1-2.4.4-150400.3.22.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libfdisk1-2.37.2-150400.8.32.2 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libfreebl3-3.101.2-150400.3.51.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libgio-2_0-0-2.70.5-150400.3.14.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libglib-2_0-0-2.70.5-150400.3.14.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libgmodule-2_0-0-2.70.5-150400.3.14.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libgobject-2_0-0-2.70.5-150400.3.14.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libgthread-2_0-0-2.70.5-150400.3.14.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libmount1-2.37.2-150400.8.32.2 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libopenssl1_1-1.1.1l-150400.7.72.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libpcap1-1.10.1-150400.3.3.2 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libsmartcols1-2.37.2-150400.8.32.2 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libsoftokn3-3.101.2-150400.3.51.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libsolv-tools-0.7.30-150400.3.27.2 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libsolv-tools-base-0.7.30-150400.3.27.2 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libsystemd0-249.17-150400.8.43.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libtiff5-4.0.9-150000.45.47.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libudev1-249.17-150400.8.43.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libuuid1-2.37.2-150400.8.32.2 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libwebp7-1.0.3-150200.3.12.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libyaml-0-2-0.1.7-150000.3.2.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libyui-ncurses-pkg16-4.3.7-150400.3.12.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libyui-ncurses16-4.3.7-150400.3.12.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libyui-qt16-4.3.7-150400.3.12.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libyui16-4.3.7-150400.3.12.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 libzypp-17.35.8-150400.3.85.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 mozilla-nss-3.101.2-150400.3.51.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 mozilla-nss-certs-3.101.2-150400.3.51.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 mozilla-nss-tools-3.101.2-150400.3.51.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 nscd-2.31-150300.86.3 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 ocfs2-kmp-default-5.14.21-150400.24.128.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 openssl-1_1-1.1.1l-150400.7.72.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 pam-1.3.0-150000.6.71.2 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 python3-PyYAML-5.4.1-150300.3.3.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 python3-bind-9.16.50-150400.5.43.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 python3-setuptools-44.1.1-150400.9.9.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 python3-solv-0.7.30-150400.3.27.2 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 python3-zypp-plugin-0.6.4-150400.13.4.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 regionServiceClientConfigGCE-4.2.0-150000.4.15.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 ruby-solv-0.7.30-150400.3.27.2 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 runc-1.1.14-150000.70.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 saptune-3.1.3-150400.15.9.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 supportutils-3.2.8-150300.7.35.33.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 suse-build-key-12.0-150000.8.52.3 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 systemd-249.17-150400.8.43.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 systemd-sysvinit-249.17-150400.8.43.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 udev-249.17-150400.8.43.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 unzip-6.00-150000.4.14.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 util-linux-2.37.2-150400.8.32.2 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 util-linux-systemd-2.37.2-150400.8.32.2 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 uuidd-2.37.2-150400.8.32.2 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 yast2-pkg-bindings-4.4.7-150400.3.16.1 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 zypper-1.14.76-150400.3.57.16 as a component of Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64 In the Linux kernel, the following vulnerability has been resolved: sch_cake: do not call cake_destroy() from cake_init() qdiscs are not supposed to call their own destroy() method from init(), because core stack already does that. syzbot was able to trigger use after free: DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock_common kernel/locking/mutex.c:586 [inline] WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740 Modules linked in: CPU: 0 PID: 21902 Comm: syz-executor189 Not tainted 5.16.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:586 [inline] RIP: 0010:__mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740 Code: 08 84 d2 0f 85 19 08 00 00 8b 05 97 38 4b 04 85 c0 0f 85 27 f7 ff ff 48 c7 c6 20 00 ac 89 48 c7 c7 a0 fe ab 89 e8 bf 76 ba ff <0f> 0b e9 0d f7 ff ff 48 8b 44 24 40 48 8d b8 c8 08 00 00 48 89 f8 RSP: 0018:ffffc9000627f290 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802315d700 RSI: ffffffff815f1db8 RDI: fffff52000c4fe44 RBP: ffff88818f28e000 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815ebb5e R11: 0000000000000000 R12: 0000000000000000 R13: dffffc0000000000 R14: ffffc9000627f458 R15: 0000000093c30000 FS: 0000555556abc400(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fda689c3303 CR3: 000000001cfbb000 CR4: 0000000000350ef0 Call Trace: <TASK> tcf_chain0_head_change_cb_del+0x2e/0x3d0 net/sched/cls_api.c:810 tcf_block_put_ext net/sched/cls_api.c:1381 [inline] tcf_block_put_ext net/sched/cls_api.c:1376 [inline] tcf_block_put+0xbc/0x130 net/sched/cls_api.c:1394 cake_destroy+0x3f/0x80 net/sched/sch_cake.c:2695 qdisc_create.constprop.0+0x9da/0x10f0 net/sched/sch_api.c:1293 tc_modify_qdisc+0x4c5/0x1980 net/sched/sch_api.c:1660 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2496 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x904/0xdf0 net/netlink/af_netlink.c:1921 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 RIP: 0033:0x7f1bb06badb9 Code: Unable to access opcode bytes at RIP 0x7f1bb06bad8f. RSP: 002b:00007fff3012a658 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f1bb06badb9 RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000003 R10: 0000000000000003 R11: 0000000000000246 R12: 00007fff3012a688 R13: 00007fff3012a6a0 R14: 00007fff3012a6e0 R15: 00000000000013c2 </TASK> CVE-2021-47598 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: Fix a deadlock in the error handler The following deadlock has been observed on a test setup: - All tags allocated - The SCSI error handler calls ufshcd_eh_host_reset_handler() - ufshcd_eh_host_reset_handler() queues work that calls ufshcd_err_handler() - ufshcd_err_handler() locks up as follows: Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt Call trace: __switch_to+0x298/0x5d8 __schedule+0x6cc/0xa94 schedule+0x12c/0x298 blk_mq_get_tag+0x210/0x480 __blk_mq_alloc_request+0x1c8/0x284 blk_get_request+0x74/0x134 ufshcd_exec_dev_cmd+0x68/0x640 ufshcd_verify_dev_init+0x68/0x35c ufshcd_probe_hba+0x12c/0x1cb8 ufshcd_host_reset_and_restore+0x88/0x254 ufshcd_reset_and_restore+0xd0/0x354 ufshcd_err_handler+0x408/0xc58 process_one_work+0x24c/0x66c worker_thread+0x3e8/0xa4c kthread+0x150/0x1b4 ret_from_fork+0x10/0x30 Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved request. CVE-2021-47622 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change The refcount leak issues take place in an error handling path. When the 3rd argument buf doesn't match with "offline", "online" or "remove", the function simply returns -EINVAL and forgets to decrease the reference count of a rpc_xprt object and a rpc_xprt_switch object increased by rpc_sysfs_xprt_kobj_get_xprt() and rpc_sysfs_xprt_kobj_get_xprt_switch(), causing reference count leaks of both unused objects. Fix this issue by jumping to the error handling path labelled with out_put when buf matches none of "offline", "online" or "remove". CVE-2021-47624 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 low A memory leak flaw was found in the Linux kernel's DMA subsystem, in the way a user calls DMA_FROM_DEVICE. This flaw allows a local user to read random memory from the kernel space. CVE-2022-0854 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate 2.1 AV:L/AC:L/Au:N/C:P/I:N/A:N An out-of-bounds (OOB) memory write flaw was found in the Linux kernel's watch_queue event notification subsystem. This flaw can overwrite parts of the kernel state, potentially allowing a local user to gain privileged access or cause a denial of service on the system. CVE-2022-0995 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important 7.2 AV:L/AC:L/Au:N/C:C/I:C/A:C Product: AndroidVersions: Android kernelAndroid ID: A-224546354References: Upstream kernel CVE-2022-20368 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2022-2964. Reason: This candidate is a reservation duplicate of CVE-2022-2964. Notes: All CVE users should reference CVE-2022-2964 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage. CVE-2022-28748 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 low In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel/pt: Fix crash with stop filters in single-range mode Add a check for !buf->single before calling pt_buffer_region_size in a place where a missing check can cause a kernel crash. Fixes a bug introduced by commit 670638477aed ("perf/x86/intel/pt: Opportunistically use single range output mode"), which added a support for PT single-range output mode. Since that commit if a PT stop filter range is hit while tracing, the kernel will crash because of a null pointer dereference in pt_handle_status due to calling pt_buffer_region_size without a ToPA configured. The commit which introduced single-range mode guarded almost all uses of the ToPA buffer variables with checks of the buf->single variable, but missed the case where tracing was stopped by the PT hardware, which happens when execution hits a configured stop filter. Tested that hitting a stop filter while PT recording successfully records a trace with this patch but crashes without this patch. CVE-2022-48713 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: xprtrdma: fix pointer derefs in error cases of rpcrdma_ep_create If there are failures then we must not leave the non-NULL pointers with the error value, otherwise `rpcrdma_ep_destroy` gets confused and tries free them, resulting in an Oops. CVE-2022-48773 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: dmaengine: ptdma: Fix the error handling path in pt_core_init() In order to free resources correctly in the error handling path of pt_core_init(), 2 goto's have to be switched. Otherwise, some resources will leak and we will try to release things that have not been allocated yet. Also move a dev_err() to a place where it is more meaningful. CVE-2022-48774 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add(): If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix memory leak by calling kobject_put(). CVE-2022-48775 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 low In the Linux kernel, the following vulnerability has been resolved: mtd: parsers: qcom: Fix missing free for pparts in cleanup Mtdpart doesn't free pparts when a cleanup function is declared. Add missing free for pparts in cleanup function for smem to fix the leak. CVE-2022-48776 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 low In the Linux kernel, the following vulnerability has been resolved: mtd: parsers: qcom: Fix kernel panic on skipped partition In the event of a skipped partition (case when the entry name is empty) the kernel panics in the cleanup function as the name entry is NULL. Rework the parser logic by first checking the real partition number and then allocate the space and set the data for the valid partitions. The logic was also fundamentally wrong as with a skipped partition, the parts number returned was incorrect by not decreasing it for the skipped partitions. CVE-2022-48777 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: gpmi: don't leak PM reference in error path If gpmi_nfc_apply_timings() fails, the PM runtime usage counter must be dropped. CVE-2022-48778 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 low In the Linux kernel, the following vulnerability has been resolved: net/smc: Avoid overwriting the copies of clcsock callback functions The callback functions of clcsock will be saved and replaced during the fallback. But if the fallback happens more than once, then the copies of these callback functions will be overwritten incorrectly, resulting in a loop call issue: clcsk->sk_error_report |- smc_fback_error_report() <------------------------------| |- smc_fback_forward_wakeup() | (loop) |- clcsock_callback() (incorrectly overwritten) | |- smc->clcsk_error_report() ------------------| So this patch fixes the issue by saving these function pointers only once in the fallback and avoiding overwriting. CVE-2022-48780 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: dsa: lantiq_gswip: fix use after free in gswip_remove() of_node_put(priv->ds->slave_mii_bus->dev.of_node) should be done before mdiobus_free(priv->ds->slave_mii_bus). CVE-2022-48783 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: cfg80211: fix race in netlink owner interface destruction My previous fix here to fix the deadlock left a race where the exact same deadlock (see the original commit referenced below) can still happen if cfg80211_destroy_ifaces() already runs while nl80211_netlink_notify() is still marking some interfaces as nl_owner_dead. The race happens because we have two loops here - first we dev_close() all the netdevs, and then we destroy them. If we also have two netdevs (first one need only be a wdev though) then we can find one during the first iteration, close it, and go to the second iteration -- but then find two, and try to destroy also the one we didn't close yet. Fix this by only iterating once. CVE-2022-48784 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: vsock: remove vsock from connected table when connect is interrupted by a signal vsock_connect() expects that the socket could already be in the TCP_ESTABLISHED state when the connecting task wakes up with a signal pending. If this happens the socket will be in the connected table, and it is not removed when the socket state is reset. In this situation it's common for the process to retry connect(), and if the connection is successful the socket will be added to the connected table a second time, corrupting the list. Prevent this by calling vsock_remove_connected() if a signal is received while waiting for a connection. This is harmless if the socket is not in the connected table, and if it is in the table then removing it will prevent list corruption from a double add. Note for backporting: this patch requires d5afa82c977e ("vsock: correct removal of socket from the list"), which is in all current stable trees except 4.9.y. CVE-2022-48786 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: iwlwifi: fix use-after-free If no firmware was present at all (or, presumably, all of the firmware files failed to parse), we end up unbinding by calling device_release_driver(), which calls remove(), which then in iwlwifi calls iwl_drv_stop(), freeing the 'drv' struct. However the new code I added will still erroneously access it after it was freed. Set 'failure=false' in this case to avoid the access, all data was already freed anyway. CVE-2022-48787 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: fix possible use-after-free in transport error_recovery work While nvme_rdma_submit_async_event_work is checking the ctrl and queue state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this check is not reliable the error recovery work must flush async_event_work before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submit_async_event and the error recovery handler itself changing the ctrl state. CVE-2022-48788 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix possible use-after-free in transport error_recovery work While nvme_tcp_submit_async_event_work is checking the ctrl and queue state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this check is not reliable the error recovery work must flush async_event_work before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submit_async_event and the error recovery handler itself changing the ctrl state. CVE-2022-48789 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: nvme: fix a possible use-after-free in controller reset during load Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl readiness for AER submission. This may lead to a use-after-free condition that was observed with nvme-tcp. The race condition may happen in the following scenario: 1. driver executes its reset_ctrl_work 2. -> nvme_stop_ctrl - flushes ctrl async_event_work 3. ctrl sends AEN which is received by the host, which in turn schedules AEN handling 4. teardown admin queue (which releases the queue socket) 5. AEN processed, submits another AER, calling the driver to submit 6. driver attempts to send the cmd ==> use-after-free In order to fix that, add ctrl state check to validate the ctrl is actually able to accept the AER submission. This addresses the above race in controller resets because the driver during teardown should: 1. change ctrl state to RESETTING 2. flush async_event_work (as well as other async work elements) So after 1,2, any other AER command will find the ctrl state to be RESETTING and bail out without submitting the AER. CVE-2022-48790 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix use-after-free for aborted TMF sas_task Currently a use-after-free may occur if a TMF sas_task is aborted before we handle the IO completion in mpi_ssp_completion(). The abort occurs due to timeout. When the timeout occurs, the SAS_TASK_STATE_ABORTED flag is set and the sas_task is freed in pm8001_exec_internal_tmf_task(). However, if the I/O completion occurs later, the I/O completion still thinks that the sas_task is available. Fix this by clearing the ccb->task if the TMF times out - the I/O completion handler does nothing if this pointer is cleared. CVE-2022-48791 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix use-after-free for aborted SSP/STP sas_task Currently a use-after-free may occur if a sas_task is aborted by the upper layer before we handle the I/O completion in mpi_ssp_completion() or mpi_sata_completion(). In this case, the following are the two steps in handling those I/O completions: - Call complete() to inform the upper layer handler of completion of the I/O. - Release driver resources associated with the sas_task in pm8001_ccb_task_free() call. When complete() is called, the upper layer may free the sas_task. As such, we should not touch the associated sas_task afterwards, but we do so in the pm8001_ccb_task_free() call. Fix by swapping the complete() and pm8001_ccb_task_free() calls ordering. CVE-2022-48792 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: x86: nSVM: fix potential NULL derefernce on nested migration Turns out that due to review feedback and/or rebases I accidentally moved the call to nested_svm_load_cr3 to be too early, before the NPT is enabled, which is very wrong to do. KVM can't even access guest memory at that point as nested NPT is needed for that, and of course it won't initialize the walk_mmu, which is main issue the patch was addressing. Fix this for real. CVE-2022-48793 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: ieee802154: at86rf230: Stop leaking skb's Upon error the ieee802154_xmit_complete() helper is not called. Only ieee802154_wake_queue() is called manually. In the Tx case we then leak the skb structure. Free the skb structure upon error before returning when appropriate. As the 'is_tx = 0' cannot be moved in the complete handler because of a possible race between the delay in switching to STATE_RX_AACK_ON and a new interrupt, we introduce an intermediate 'was_tx' boolean just for this purpose. There is no Fixes tag applying here, many changes have been made on this area and the issue kind of always existed. CVE-2022-48794 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 low In the Linux kernel, the following vulnerability has been resolved: iommu: Fix potential use-after-free during probe Kasan has reported the following use after free on dev->iommu. when a device probe fails and it is in process of freeing dev->iommu in dev_iommu_free function, a deferred_probe_work_func runs in parallel and tries to access dev->iommu->fwspec in of_iommu_configure path thus causing use after free. BUG: KASAN: use-after-free in of_iommu_configure+0xb4/0x4a4 Read of size 8 at addr ffffff87a2f1acb8 by task kworker/u16:2/153 Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x33c show_stack+0x18/0x24 dump_stack_lvl+0x16c/0x1e0 print_address_description+0x84/0x39c __kasan_report+0x184/0x308 kasan_report+0x50/0x78 __asan_load8+0xc0/0xc4 of_iommu_configure+0xb4/0x4a4 of_dma_configure_id+0x2fc/0x4d4 platform_dma_configure+0x40/0x5c really_probe+0x1b4/0xb74 driver_probe_device+0x11c/0x228 __device_attach_driver+0x14c/0x304 bus_for_each_drv+0x124/0x1b0 __device_attach+0x25c/0x334 device_initial_probe+0x24/0x34 bus_probe_device+0x78/0x134 deferred_probe_work_func+0x130/0x1a8 process_one_work+0x4c8/0x970 worker_thread+0x5c8/0xaec kthread+0x1f8/0x220 ret_from_fork+0x10/0x18 Allocated by task 1: ____kasan_kmalloc+0xd4/0x114 __kasan_kmalloc+0x10/0x1c kmem_cache_alloc_trace+0xe4/0x3d4 __iommu_probe_device+0x90/0x394 probe_iommu_group+0x70/0x9c bus_for_each_dev+0x11c/0x19c bus_iommu_probe+0xb8/0x7d4 bus_set_iommu+0xcc/0x13c arm_smmu_bus_init+0x44/0x130 [arm_smmu] arm_smmu_device_probe+0xb88/0xc54 [arm_smmu] platform_drv_probe+0xe4/0x13c really_probe+0x2c8/0xb74 driver_probe_device+0x11c/0x228 device_driver_attach+0xf0/0x16c __driver_attach+0x80/0x320 bus_for_each_dev+0x11c/0x19c driver_attach+0x38/0x48 bus_add_driver+0x1dc/0x3a4 driver_register+0x18c/0x244 __platform_driver_register+0x88/0x9c init_module+0x64/0xff4 [arm_smmu] do_one_initcall+0x17c/0x2f0 do_init_module+0xe8/0x378 load_module+0x3f80/0x4a40 __se_sys_finit_module+0x1a0/0x1e4 __arm64_sys_finit_module+0x44/0x58 el0_svc_common+0x100/0x264 do_el0_svc+0x38/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0x68/0xac el0_sync+0x160/0x180 Freed by task 1: kasan_set_track+0x4c/0x84 kasan_set_free_info+0x28/0x4c ____kasan_slab_free+0x120/0x15c __kasan_slab_free+0x18/0x28 slab_free_freelist_hook+0x204/0x2fc kfree+0xfc/0x3a4 __iommu_probe_device+0x284/0x394 probe_iommu_group+0x70/0x9c bus_for_each_dev+0x11c/0x19c bus_iommu_probe+0xb8/0x7d4 bus_set_iommu+0xcc/0x13c arm_smmu_bus_init+0x44/0x130 [arm_smmu] arm_smmu_device_probe+0xb88/0xc54 [arm_smmu] platform_drv_probe+0xe4/0x13c really_probe+0x2c8/0xb74 driver_probe_device+0x11c/0x228 device_driver_attach+0xf0/0x16c __driver_attach+0x80/0x320 bus_for_each_dev+0x11c/0x19c driver_attach+0x38/0x48 bus_add_driver+0x1dc/0x3a4 driver_register+0x18c/0x244 __platform_driver_register+0x88/0x9c init_module+0x64/0xff4 [arm_smmu] do_one_initcall+0x17c/0x2f0 do_init_module+0xe8/0x378 load_module+0x3f80/0x4a40 __se_sys_finit_module+0x1a0/0x1e4 __arm64_sys_finit_module+0x44/0x58 el0_svc_common+0x100/0x264 do_el0_svc+0x38/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0x68/0xac el0_sync+0x160/0x180 Fix this by setting dev->iommu to NULL first and then freeing dev_iommu structure in dev_iommu_free function. CVE-2022-48796 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: mm: don't try to NUMA-migrate COW pages that have other uses Oded Gabbay reports that enabling NUMA balancing causes corruption with his Gaudi accelerator test load: "All the details are in the bug, but the bottom line is that somehow, this patch causes corruption when the numa balancing feature is enabled AND we don't use process affinity AND we use GUP to pin pages so our accelerator can DMA to/from system memory. Either disabling numa balancing, using process affinity to bind to specific numa-node or reverting this patch causes the bug to disappear" and Oded bisected the issue to commit 09854ba94c6a ("mm: do_wp_page() simplification"). Now, the NUMA balancing shouldn't actually be changing the writability of a page, and as such shouldn't matter for COW. But it appears it does. Suspicious. However, regardless of that, the condition for enabling NUMA faults in change_pte_range() is nonsensical. It uses "page_mapcount(page)" to decide if a COW page should be NUMA-protected or not, and that makes absolutely no sense. The number of mappings a page has is irrelevant: not only does GUP get a reference to a page as in Oded's case, but the other mappings migth be paged out and the only reference to them would be in the page count. Since we should never try to NUMA-balance a page that we can't move anyway due to other references, just fix the code to use 'page_count()'. Oded confirms that that fixes his issue. Now, this does imply that something in NUMA balancing ends up changing page protections (other than the obvious one of making the page inaccessible to get the NUMA faulting information). Otherwise the COW simplification wouldn't matter - since doing the GUP on the page would make sure it's writable. The cause of that permission change would be good to figure out too, since it clearly results in spurious COW events - but fixing the nonsensical test that just happened to work before is obviously the CorrectThing(tm) to do regardless. CVE-2022-48797 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: s390/cio: verify the driver availability for path_event call If no driver is attached to a device or the driver does not provide the path_event function, an FCES path-event on this device could end up in a kernel-panic. Verify the driver availability before the path_event function call. CVE-2022-48798 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: perf: Fix list corruption in perf_cgroup_switch() There's list corruption on cgrp_cpuctx_list. This happens on the following path: perf_cgroup_switch: list_for_each_entry(cgrp_cpuctx_list) cpu_ctx_sched_in ctx_sched_in ctx_pinned_sched_in merge_sched_in perf_cgroup_event_disable: remove the event from the list Use list_for_each_entry_safe() to allow removing an entry during iteration. CVE-2022-48799 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: mm: vmscan: remove deadlock due to throttling failing to make progress A soft lockup bug in kcompactd was reported in a private bugzilla with the following visible in dmesg; watchdog: BUG: soft lockup - CPU#33 stuck for 26s! [kcompactd0:479] watchdog: BUG: soft lockup - CPU#33 stuck for 52s! [kcompactd0:479] watchdog: BUG: soft lockup - CPU#33 stuck for 78s! [kcompactd0:479] watchdog: BUG: soft lockup - CPU#33 stuck for 104s! [kcompactd0:479] The machine had 256G of RAM with no swap and an earlier failed allocation indicated that node 0 where kcompactd was run was potentially unreclaimable; Node 0 active_anon:29355112kB inactive_anon:2913528kB active_file:0kB inactive_file:0kB unevictable:64kB isolated(anon):0kB isolated(file):0kB mapped:8kB dirty:0kB writeback:0kB shmem:26780kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 23480320kB writeback_tmp:0kB kernel_stack:2272kB pagetables:24500kB all_unreclaimable? yes Vlastimil Babka investigated a crash dump and found that a task migrating pages was trying to drain PCP lists; PID: 52922 TASK: ffff969f820e5000 CPU: 19 COMMAND: "kworker/u128:3" Call Trace: __schedule schedule schedule_timeout wait_for_completion __flush_work __drain_all_pages __alloc_pages_slowpath.constprop.114 __alloc_pages alloc_migration_target migrate_pages migrate_to_node do_migrate_pages cpuset_migrate_mm_workfn process_one_work worker_thread kthread ret_from_fork This failure is specific to CONFIG_PREEMPT=n builds. The root of the problem is that kcompact0 is not rescheduling on a CPU while a task that has isolated a large number of the pages from the LRU is waiting on kcompact0 to reschedule so the pages can be released. While shrink_inactive_list() only loops once around too_many_isolated, reclaim can continue without rescheduling if sc->skipped_deactivate == 1 which could happen if there was no file LRU and the inactive anon list was not low. CVE-2022-48800 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 low In the Linux kernel, the following vulnerability has been resolved: iio: buffer: Fix file related error handling in IIO_BUFFER_GET_FD_IOCTL If we fail to copy the just created file descriptor to userland, we try to clean up by putting back 'fd' and freeing 'ib'. The code uses put_unused_fd() for the former which is wrong, as the file descriptor was already published by fd_install() which gets called internally by anon_inode_getfd(). This makes the error handling code leaving a half cleaned up file descriptor table around and a partially destructed 'file' object, allowing userland to play use-after-free tricks on us, by abusing the still usable fd and making the code operate on a dangling 'file->private_data' pointer. Instead of leaving the kernel in a partially corrupted state, don't attempt to explicitly clean up and leave this to the process exit path that'll release any still valid fds, including the one created by the previous call to anon_inode_getfd(). Simply return -EFAULT to indicate the error. CVE-2022-48801 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important In the Linux kernel, the following vulnerability has been resolved: phy: ti: Fix missing sentinel for clk_div_table _get_table_maxdiv() tries to access "clk_div_table" array out of bound defined in phy-j721e-wiz.c. Add a sentinel entry to prevent the following global-out-of-bounds error reported by enabling KASAN. [ 9.552392] BUG: KASAN: global-out-of-bounds in _get_maxdiv+0xc0/0x148 [ 9.558948] Read of size 4 at addr ffff8000095b25a4 by task kworker/u4:1/38 [ 9.565926] [ 9.567441] CPU: 1 PID: 38 Comm: kworker/u4:1 Not tainted 5.16.0-116492-gdaadb3bd0e8d-dirty #360 [ 9.576242] Hardware name: Texas Instruments J721e EVM (DT) [ 9.581832] Workqueue: events_unbound deferred_probe_work_func [ 9.587708] Call trace: [ 9.590174] dump_backtrace+0x20c/0x218 [ 9.594038] show_stack+0x18/0x68 [ 9.597375] dump_stack_lvl+0x9c/0xd8 [ 9.601062] print_address_description.constprop.0+0x78/0x334 [ 9.606830] kasan_report+0x1f0/0x260 [ 9.610517] __asan_load4+0x9c/0xd8 [ 9.614030] _get_maxdiv+0xc0/0x148 [ 9.617540] divider_determine_rate+0x88/0x488 [ 9.622005] divider_round_rate_parent+0xc8/0x124 [ 9.626729] wiz_clk_div_round_rate+0x54/0x68 [ 9.631113] clk_core_determine_round_nolock+0x124/0x158 [ 9.636448] clk_core_round_rate_nolock+0x68/0x138 [ 9.641260] clk_core_set_rate_nolock+0x268/0x3a8 [ 9.645987] clk_set_rate+0x50/0xa8 [ 9.649499] cdns_sierra_phy_init+0x88/0x248 [ 9.653794] phy_init+0x98/0x108 [ 9.657046] cdns_pcie_enable_phy+0xa0/0x170 [ 9.661340] cdns_pcie_init_phy+0x250/0x2b0 [ 9.665546] j721e_pcie_probe+0x4b8/0x798 [ 9.669579] platform_probe+0x8c/0x108 [ 9.673350] really_probe+0x114/0x630 [ 9.677037] __driver_probe_device+0x18c/0x220 [ 9.681505] driver_probe_device+0xac/0x150 [ 9.685712] __device_attach_driver+0xec/0x170 [ 9.690178] bus_for_each_drv+0xf0/0x158 [ 9.694124] __device_attach+0x184/0x210 [ 9.698070] device_initial_probe+0x14/0x20 [ 9.702277] bus_probe_device+0xec/0x100 [ 9.706223] deferred_probe_work_func+0x124/0x180 [ 9.710951] process_one_work+0x4b0/0xbc0 [ 9.714983] worker_thread+0x74/0x5d0 [ 9.718668] kthread+0x214/0x230 [ 9.721919] ret_from_fork+0x10/0x20 [ 9.725520] [ 9.727032] The buggy address belongs to the variable: [ 9.732183] clk_div_table+0x24/0x440 CVE-2022-48803 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: vt_ioctl: fix array_index_nospec in vt_setactivate array_index_nospec ensures that an out-of-bounds value is set to zero on the transient path. Decreasing the value by one afterwards causes a transient integer underflow. vsa.console should be decreased first and then sanitized with array_index_nospec. Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU Amsterdam. CVE-2022-48804 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixup ax88179_rx_fixup() contains several out-of-bounds accesses that can be triggered by a malicious (or defective) USB device, in particular: - The metadata array (hdr_off..hdr_off+2*pkt_cnt) can be out of bounds, causing OOB reads and (on big-endian systems) OOB endianness flips. - A packet can overlap the metadata array, causing a later OOB endianness flip to corrupt data used by a cloned SKB that has already been handed off into the network stack. - A packet SKB can be constructed whose tail is far beyond its end, causing out-of-bounds heap data to be considered part of the SKB's data. I have tested that this can be used by a malicious USB device to send a bogus ICMPv6 Echo Request and receive an ICMPv6 Echo Reply in response that contains random kernel heap data. It's probably also possible to get OOB writes from this on a little-endian system somehow - maybe by triggering skb_cow() via IP options processing -, but I haven't tested that. CVE-2022-48805 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: eeprom: ee1004: limit i2c reads to I2C_SMBUS_BLOCK_MAX Commit effa453168a7 ("i2c: i801: Don't silently correct invalid transfer size") revealed that ee1004_eeprom_read() did not properly limit how many bytes to read at once. In particular, i2c_smbus_read_i2c_block_data_or_emulated() takes the length to read as an u8. If count == 256 after taking into account the offset and page boundary, the cast to u8 overflows. And this is common when user space tries to read the entire EEPROM at once. To fix it, limit each read to I2C_SMBUS_BLOCK_MAX (32) bytes, already the maximum length i2c_smbus_read_i2c_block_data_or_emulated() allows. CVE-2022-48806 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: ice: Fix KASAN error in LAG NETDEV_UNREGISTER handler Currently, the same handler is called for both a NETDEV_BONDING_INFO LAG unlink notification as for a NETDEV_UNREGISTER call. This is causing a problem though, since the netdev_notifier_info passed has a different structure depending on which event is passed. The problem manifests as a call trace from a BUG: KASAN stack-out-of-bounds error. Fix this by creating a handler specific to NETDEV_UNREGISTER that only is passed valid elements in the netdev_notifier_info struct for the NETDEV_UNREGISTER event. Also included is the removal of an unbalanced dev_put on the peer_netdev and related braces. CVE-2022-48807 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important In the Linux kernel, the following vulnerability has been resolved: ibmvnic: don't release napi in __ibmvnic_open() If __ibmvnic_open() encounters an error such as when setting link state, it calls release_resources() which frees the napi structures needlessly. Instead, have __ibmvnic_open() only clean up the work it did so far (i.e. disable napi and irqs) and leave the rest to the callers. If caller of __ibmvnic_open() is ibmvnic_open(), it should release the resources immediately. If the caller is do_reset() or do_hard_reset(), they will release the resources on the next reset. This fixes following crash that occurred when running the drmgr command several times to add/remove a vnic interface: [102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq [102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq [102056] ibmvnic 30000003 env3: Replenished 8 pools Kernel attempted to read user page (10) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000010 Faulting instruction address: 0xc000000000a3c840 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries ... CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1 Workqueue: events_long __ibmvnic_reset [ibmvnic] NIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820 REGS: c0000000548e37e0 TRAP: 0300 Not tainted (5.16.0-rc5-autotest-g6441998e2e37) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28248484 XER: 00000004 CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0 GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000 ... NIP [c000000000a3c840] napi_enable+0x20/0xc0 LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic] Call Trace: [c0000000548e3a80] [0000000000000006] 0x6 (unreliable) [c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic] [c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic] [c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570 [c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660 [c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0 [c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: 7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010 38a0fff6 e92d1100 f9210028 39200000 <e9030010> f9010020 60420000 e9210020 ---[ end trace 5f8033b08fd27706 ]--- CVE-2022-48811 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: dsa: lantiq_gswip: don't use devres for mdiobus As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The GSWIP switch is a platform device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the GSWIP switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The gswip driver has the code structure in place for orderly mdiobus removal, so just replace devm_mdiobus_alloc() with the non-devres variant, and add manual free where necessary, to ensure that we don't let devres free a still-registered bus. CVE-2022-48812 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: dsa: felix: don't use devres for mdiobus As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The Felix VSC9959 switch is a PCI device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the felix switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The felix driver has the code structure in place for orderly mdiobus removal, so just replace devm_mdiobus_alloc_size() with the non-devres variant, and add manual free where necessary, to ensure that we don't let devres free a still-registered bus. CVE-2022-48813 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: dsa: seville: register the mdiobus under devres As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The Seville VSC9959 switch is a platform device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the seville switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The seville driver has a code structure that could accommodate both the mdiobus_unregister and mdiobus_free calls, but it has an external dependency upon mscc_miim_setup() from mdio-mscc-miim.c, which calls devm_mdiobus_alloc_size() on its behalf. So rather than restructuring that, and exporting yet one more symbol mscc_miim_teardown(), let's work with devres and replace of_mdiobus_register with the devres variant. When we use all-devres, we can ensure that devres doesn't free a still-registered bus (it either runs both callbacks, or none). CVE-2022-48814 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: don't use devres for mdiobus As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The Starfighter 2 is a platform device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the bcm_sf2 switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The bcm_sf2 driver has the code structure in place for orderly mdiobus removal, so just replace devm_mdiobus_alloc() with the non-devres variant, and add manual free where necessary, to ensure that we don't let devres free a still-registered bus. CVE-2022-48815 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: SUNRPC: lock against ->sock changing during sysfs read ->sock can be set to NULL asynchronously unless ->recv_mutex is held. So it is important to hold that mutex. Otherwise a sysfs read can trigger an oops. Commit 17f09d3f619a ("SUNRPC: Check if the xprt is connected before handling sysfs reads") appears to attempt to fix this problem, but it only narrows the race window. CVE-2022-48816 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: dsa: ar9331: register the mdiobus under devres As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The ar9331 is an MDIO device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the ar9331 switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The ar9331 driver doesn't have a complex code structure for mdiobus removal, so just replace of_mdiobus_register with the devres variant in order to be all-devres and ensure that we don't free a still-registered bus. CVE-2022-48817 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: don't use devres for mdiobus As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The mv88e6xxx is an MDIO device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the Marvell switch driver on shutdown. systemd-shutdown[1]: Powering off. mv88e6085 0x0000000008b96000:00 sw_gl0: Link is Down fsl-mc dpbp.9: Removing from iommu group 7 fsl-mc dpbp.8: Removing from iommu group 7 ------------[ cut here ]------------ kernel BUG at drivers/net/phy/mdio_bus.c:677! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00040-gdc05f73788e5 #15 pc : mdiobus_free+0x44/0x50 lr : devm_mdiobus_free+0x10/0x20 Call trace: mdiobus_free+0x44/0x50 devm_mdiobus_free+0x10/0x20 devres_release_all+0xa0/0x100 __device_release_driver+0x190/0x220 device_release_driver_internal+0xac/0xb0 device_links_unbind_consumers+0xd4/0x100 __device_release_driver+0x4c/0x220 device_release_driver_internal+0xac/0xb0 device_links_unbind_consumers+0xd4/0x100 __device_release_driver+0x94/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_device_remove+0x24/0x40 __fsl_mc_device_remove+0xc/0x20 device_for_each_child+0x58/0xa0 dprc_remove+0x90/0xb0 fsl_mc_driver_remove+0x20/0x5c __device_release_driver+0x21c/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_bus_remove+0x80/0x100 fsl_mc_bus_shutdown+0xc/0x1c platform_shutdown+0x20/0x30 device_shutdown+0x154/0x330 kernel_power_off+0x34/0x6c __do_sys_reboot+0x15c/0x250 __arm64_sys_reboot+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x4c/0x150 el0_svc+0x24/0xb0 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x178/0x17c So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The Marvell driver already has a good structure for mdiobus removal, so just plug in mdiobus_free and get rid of devres. CVE-2022-48818 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: phy: stm32: fix a refcount leak in stm32_usbphyc_pll_enable() This error path needs to decrement "usbphyc->n_pll_cons.counter" before returning. CVE-2022-48820 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: avoid double fput() on failed usercopy If the copy back to userland fails for the FASTRPC_IOCTL_ALLOC_DMA_BUFF ioctl(), we shouldn't assume that 'buf->dmabuf' is still valid. In fact, dma_buf_fd() called fd_install() before, i.e. "consumed" one reference, leaving us with none. Calling dma_buf_put() will therefore put a reference we no longer own, leading to a valid file descritor table entry for an already released 'file' object which is a straight use-after-free. Simply avoid calling dma_buf_put() and rely on the process exit code to do the necessary cleanup, if needed, i.e. if the file descriptor is still valid. CVE-2022-48821 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important In the Linux kernel, the following vulnerability has been resolved: usb: f_fs: Fix use-after-free for epfile Consider a case where ffs_func_eps_disable is called from ffs_func_disable as part of composition switch and at the same time ffs_epfile_release get called from userspace. ffs_epfile_release will free up the read buffer and call ffs_data_closed which in turn destroys ffs->epfiles and mark it as NULL. While this was happening the driver has already initialized the local epfile in ffs_func_eps_disable which is now freed and waiting to acquire the spinlock. Once spinlock is acquired the driver proceeds with the stale value of epfile and tries to free the already freed read buffer causing use-after-free. Following is the illustration of the race: CPU1 CPU2 ffs_func_eps_disable epfiles (local copy) ffs_epfile_release ffs_data_closed if (last file closed) ffs_data_reset ffs_data_clear ffs_epfiles_destroy spin_lock dereference epfiles Fix this races by taking epfiles local copy & assigning it under spinlock and if epfiles(local) is null then update it in ffs->epfiles then finally destroy it. Extending the scope further from the race, protecting the ep related structures, and concurrent accesses. CVE-2022-48822 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Fix refcount issue when LOGO is received during TMF Hung task call trace was seen during LOGO processing. [ 974.309060] [0000:00:00.0]:[qedf_eh_device_reset:868]: 1:0:2:0: LUN RESET Issued... [ 974.309065] [0000:00:00.0]:[qedf_initiate_tmf:2422]: tm_flags 0x10 sc_cmd 00000000c16b930f op = 0x2a target_id = 0x2 lun=0 [ 974.309178] [0000:00:00.0]:[qedf_initiate_tmf:2431]: portid=016900 tm_flags =LUN RESET [ 974.309222] [0000:00:00.0]:[qedf_initiate_tmf:2438]: orig io_req = 00000000ec78df8f xid = 0x180 ref_cnt = 1. [ 974.309625] host1: rport 016900: Received LOGO request while in state Ready [ 974.309627] host1: rport 016900: Delete port [ 974.309642] host1: rport 016900: work event 3 [ 974.309644] host1: rport 016900: lld callback ev 3 [ 974.313243] [0000:61:00.2]:[qedf_execute_tmf:2383]:1: fcport is uploading, not executing flush. [ 974.313295] [0000:61:00.2]:[qedf_execute_tmf:2400]:1: task mgmt command success... [ 984.031088] INFO: task jbd2/dm-15-8:7645 blocked for more than 120 seconds. [ 984.031136] Not tainted 4.18.0-305.el8.x86_64 #1 [ 984.031166] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 984.031209] jbd2/dm-15-8 D 0 7645 2 0x80004080 [ 984.031212] Call Trace: [ 984.031222] __schedule+0x2c4/0x700 [ 984.031230] ? unfreeze_partials.isra.83+0x16e/0x1a0 [ 984.031233] ? bit_wait_timeout+0x90/0x90 [ 984.031235] schedule+0x38/0xa0 [ 984.031238] io_schedule+0x12/0x40 [ 984.031240] bit_wait_io+0xd/0x50 [ 984.031243] __wait_on_bit+0x6c/0x80 [ 984.031248] ? free_buffer_head+0x21/0x50 [ 984.031251] out_of_line_wait_on_bit+0x91/0xb0 [ 984.031257] ? init_wait_var_entry+0x50/0x50 [ 984.031268] jbd2_journal_commit_transaction+0x112e/0x19f0 [jbd2] [ 984.031280] kjournald2+0xbd/0x270 [jbd2] [ 984.031284] ? finish_wait+0x80/0x80 [ 984.031291] ? commit_timeout+0x10/0x10 [jbd2] [ 984.031294] kthread+0x116/0x130 [ 984.031300] ? kthread_flush_work_fn+0x10/0x10 [ 984.031305] ret_from_fork+0x1f/0x40 There was a ref count issue when LOGO is received during TMF. This leads to one of the I/Os hanging with the driver. Fix the ref count. CVE-2022-48823 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 low In the Linux kernel, the following vulnerability has been resolved: scsi: myrs: Fix crash in error case In myrs_detect(), cs->disable_intr is NULL when privdata->hw_init() fails with non-zero. In this case, myrs_cleanup(cs) will call a NULL ptr and crash the kernel. [ 1.105606] myrs 0000:00:03.0: Unknown Initialization Error 5A [ 1.105872] myrs 0000:00:03.0: Failed to initialize Controller [ 1.106082] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.110774] Call Trace: [ 1.110950] myrs_cleanup+0xe4/0x150 [myrs] [ 1.111135] myrs_probe.cold+0x91/0x56a [myrs] [ 1.111302] ? DAC960_GEM_intr_handler+0x1f0/0x1f0 [myrs] [ 1.111500] local_pci_probe+0x48/0x90 CVE-2022-48824 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Add stag_work to all the vports Call trace seen when creating NPIV ports, only 32 out of 64 show online. stag work was not initialized for vport, hence initialize the stag work. WARNING: CPU: 8 PID: 645 at kernel/workqueue.c:1635 __queue_delayed_work+0x68/0x80 CPU: 8 PID: 645 Comm: kworker/8:1 Kdump: loaded Tainted: G IOE --------- -- 4.18.0-348.el8.x86_64 #1 Hardware name: Dell Inc. PowerEdge MX740c/0177V9, BIOS 2.12.2 07/09/2021 Workqueue: events fc_lport_timeout [libfc] RIP: 0010:__queue_delayed_work+0x68/0x80 Code: 89 b2 88 00 00 00 44 89 82 90 00 00 00 48 01 c8 48 89 42 50 41 81 f8 00 20 00 00 75 1d e9 60 24 07 00 44 89 c7 e9 98 f6 ff ff <0f> 0b eb c5 0f 0b eb a1 0f 0b eb a7 0f 0b eb ac 44 89 c6 e9 40 23 RSP: 0018:ffffae514bc3be40 EFLAGS: 00010006 RAX: ffff8d25d6143750 RBX: 0000000000000202 RCX: 0000000000000002 RDX: ffff8d2e31383748 RSI: ffff8d25c000d600 RDI: ffff8d2e31383788 RBP: ffff8d2e31380de0 R08: 0000000000002000 R09: ffff8d2e31383750 R10: ffffffffc0c957e0 R11: ffff8d2624800000 R12: ffff8d2e31380a58 R13: ffff8d2d915eb000 R14: ffff8d25c499b5c0 R15: ffff8d2e31380e18 FS: 0000000000000000(0000) GS:ffff8d2d1fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055fd0484b8b8 CR3: 00000008ffc10006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: queue_delayed_work_on+0x36/0x40 qedf_elsct_send+0x57/0x60 [qedf] fc_lport_enter_flogi+0x90/0xc0 [libfc] fc_lport_timeout+0xb7/0x140 [libfc] process_one_work+0x1a7/0x360 ? create_worker+0x1a0/0x1a0 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x35/0x40 ---[ end trace 008f00f722f2c2ff ]-- Initialize stag work for all the vports. CVE-2022-48825 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 low In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Fix deadlock on DSI device attach error DSI device attach to DSI host will be done with host device's lock held. Un-registering host in "device attach" error path (ex: probe retry) will result in deadlock with below call trace and non operational DSI display. Startup Call trace: [ 35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8 [ 35.043048] mutex_lock_nested+0x7c/0xc8 [ 35.043060] device_del+0x4c/0x3e8 [ 35.043075] device_unregister+0x20/0x40 [ 35.043082] mipi_dsi_remove_device_fn+0x18/0x28 [ 35.043093] device_for_each_child+0x68/0xb0 [ 35.043105] mipi_dsi_host_unregister+0x40/0x90 [ 35.043115] vc4_dsi_host_attach+0xf0/0x120 [vc4] [ 35.043199] mipi_dsi_attach+0x30/0x48 [ 35.043209] tc358762_probe+0x128/0x164 [tc358762] [ 35.043225] mipi_dsi_drv_probe+0x28/0x38 [ 35.043234] really_probe+0xc0/0x318 [ 35.043244] __driver_probe_device+0x80/0xe8 [ 35.043254] driver_probe_device+0xb8/0x118 [ 35.043263] __device_attach_driver+0x98/0xe8 [ 35.043273] bus_for_each_drv+0x84/0xd8 [ 35.043281] __device_attach+0xf0/0x150 [ 35.043290] device_initial_probe+0x1c/0x28 [ 35.043300] bus_probe_device+0xa4/0xb0 [ 35.043308] deferred_probe_work_func+0xa0/0xe0 [ 35.043318] process_one_work+0x254/0x700 [ 35.043330] worker_thread+0x4c/0x448 [ 35.043339] kthread+0x19c/0x1a8 [ 35.043348] ret_from_fork+0x10/0x20 Shutdown Call trace: [ 365.565417] Call trace: [ 365.565423] __switch_to+0x148/0x200 [ 365.565452] __schedule+0x340/0x9c8 [ 365.565467] schedule+0x48/0x110 [ 365.565479] schedule_timeout+0x3b0/0x448 [ 365.565496] wait_for_completion+0xac/0x138 [ 365.565509] __flush_work+0x218/0x4e0 [ 365.565523] flush_work+0x1c/0x28 [ 365.565536] wait_for_device_probe+0x68/0x158 [ 365.565550] device_shutdown+0x24/0x348 [ 365.565561] kernel_restart_prepare+0x40/0x50 [ 365.565578] kernel_restart+0x20/0x70 [ 365.565591] __do_sys_reboot+0x10c/0x220 [ 365.565605] __arm64_sys_reboot+0x2c/0x38 [ 365.565619] invoke_syscall+0x4c/0x110 [ 365.565634] el0_svc_common.constprop.3+0xfc/0x120 [ 365.565648] do_el0_svc+0x2c/0x90 [ 365.565661] el0_svc+0x4c/0xf0 [ 365.565671] el0t_64_sync_handler+0x90/0xb8 [ 365.565682] el0t_64_sync+0x180/0x184 CVE-2022-48826 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix the behavior of READ near OFFSET_MAX Dan Aloni reports: > Due to commit 8cfb9015280d ("NFS: Always provide aligned buffers to > the RPC read layers") on the client, a read of 0xfff is aligned up > to server rsize of 0x1000. > > As a result, in a test where the server has a file of size > 0x7fffffffffffffff, and the client tries to read from the offset > 0x7ffffffffffff000, the read causes loff_t overflow in the server > and it returns an NFS code of EINVAL to the client. The client as > a result indefinitely retries the request. The Linux NFS client does not handle NFS?ERR_INVAL, even though all NFS specifications permit servers to return that status code for a READ. Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed and return a short result. Set the EOF flag in the result to prevent the client from retrying the READ request. This behavior appears to be consistent with Solaris NFS servers. Note that NFSv3 and NFSv4 use u64 offset values on the wire. These must be converted to loff_t internally before use -- an implicit type cast is not adequate for this purpose. Otherwise VFS checks against sb->s_maxbytes do not work properly. CVE-2022-48827 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix ia_size underflow iattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and NFSv4 both define file size as an unsigned 64-bit type. Thus there is a range of valid file size values an NFS client can send that is already larger than Linux can handle. Currently decode_fattr4() dumps a full u64 value into ia_size. If that value happens to be larger than S64_MAX, then ia_size underflows. I'm about to fix up the NFSv3 behavior as well, so let's catch the underflow in the common code path: nfsd_setattr(). CVE-2022-48828 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix NFSv3 SETATTR/CREATE's handling of large file sizes iattr::ia_size is a loff_t, so these NFSv3 procedures must be careful to deal with incoming client size values that are larger than s64_max without corrupting the value. Silently capping the value results in storing a different value than the client passed in which is unexpected behavior, so remove the min_t() check in decode_sattr3(). Note that RFC 1813 permits only the WRITE procedure to return NFS3ERR_FBIG. We believe that NFSv3 reference implementations also return NFS3ERR_FBIG when ia_size is too large. CVE-2022-48829 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix potential CAN frame reception race in isotp_rcv() When receiving a CAN frame the current code logic does not consider concurrently receiving processes which do not show up in real world usage. Ziyang Xuan writes: The following syz problem is one of the scenarios. so->rx.len is changed by isotp_rcv_ff() during isotp_rcv_cf(), so->rx.len equals 0 before alloc_skb() and equals 4096 after alloc_skb(). That will trigger skb_over_panic() in skb_put(). ======================================================= CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc8-syzkaller #0 RIP: 0010:skb_panic+0x16c/0x16e net/core/skbuff.c:113 Call Trace: <TASK> skb_over_panic net/core/skbuff.c:118 [inline] skb_put.cold+0x24/0x24 net/core/skbuff.c:1990 isotp_rcv_cf net/can/isotp.c:570 [inline] isotp_rcv+0xa38/0x1e30 net/can/isotp.c:668 deliver net/can/af_can.c:574 [inline] can_rcv_filter+0x445/0x8d0 net/can/af_can.c:635 can_receive+0x31d/0x580 net/can/af_can.c:665 can_rcv+0x120/0x1c0 net/can/af_can.c:696 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5465 __netif_receive_skb+0x24/0x1b0 net/core/dev.c:5579 Therefore we make sure the state changes and data structures stay consistent at CAN frame reception time by adding a spin_lock in isotp_rcv(). This fixes the issue reported by syzkaller but does not affect real world operation. CVE-2022-48830 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: ima: fix reference leak in asymmetric_verify() Don't leak a reference to the key if its algorithm is unknown. CVE-2022-48831 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: usbtmc: Fix bug in pipe direction for control transfers The syzbot fuzzer reported a minor bug in the usbtmc driver: usb 5-1: BOGUS control dir, pipe 80001e80 doesn't match bRequestType 0 WARNING: CPU: 0 PID: 3813 at drivers/usb/core/urb.c:412 usb_submit_urb+0x13a5/0x1970 drivers/usb/core/urb.c:410 Modules linked in: CPU: 0 PID: 3813 Comm: syz-executor122 Not tainted 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0 ... Call Trace: <TASK> usb_start_wait_urb+0x113/0x530 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x2a5/0x4b0 drivers/usb/core/message.c:153 usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1947 [inline] The problem is that usbtmc_ioctl_request() uses usb_rcvctrlpipe() for all of its transfers, whether they are in or out. It's easy to fix. CVE-2022-48834 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 low In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Page fault in reply q processing A page fault was encountered in mpt3sas on a LUN reset error path: [ 145.763216] mpt3sas_cm1: Task abort tm failed: handle(0x0002),timeout(30) tr_method(0x0) smid(3) msix_index(0) [ 145.778932] scsi 1:0:0:0: task abort: FAILED scmd(0x0000000024ba29a2) [ 145.817307] scsi 1:0:0:0: attempting device reset! scmd(0x0000000024ba29a2) [ 145.827253] scsi 1:0:0:0: [sg1] tag#2 CDB: Receive Diagnostic 1c 01 01 ff fc 00 [ 145.837617] scsi target1:0:0: handle(0x0002), sas_address(0x500605b0000272b9), phy(0) [ 145.848598] scsi target1:0:0: enclosure logical id(0x500605b0000272b8), slot(0) [ 149.858378] mpt3sas_cm1: Poll ReplyDescriptor queues for completion of smid(0), task_type(0x05), handle(0x0002) [ 149.875202] BUG: unable to handle page fault for address: 00000007fffc445d [ 149.885617] #PF: supervisor read access in kernel mode [ 149.894346] #PF: error_code(0x0000) - not-present page [ 149.903123] PGD 0 P4D 0 [ 149.909387] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 149.917417] CPU: 24 PID: 3512 Comm: scsi_eh_1 Kdump: loaded Tainted: G S O 5.10.89-altav-1 #1 [ 149.934327] Hardware name: DDN 200NVX2 /200NVX2-MB , BIOS ATHG2.2.02.01 09/10/2021 [ 149.951871] RIP: 0010:_base_process_reply_queue+0x4b/0x900 [mpt3sas] [ 149.961889] Code: 0f 84 22 02 00 00 8d 48 01 49 89 fd 48 8d 57 38 f0 0f b1 4f 38 0f 85 d8 01 00 00 49 8b 45 10 45 31 e4 41 8b 55 0c 48 8d 1c d0 <0f> b6 03 83 e0 0f 3c 0f 0f 85 a2 00 00 00 e9 e6 01 00 00 0f b7 ee [ 149.991952] RSP: 0018:ffffc9000f1ebcb8 EFLAGS: 00010246 [ 150.000937] RAX: 0000000000000055 RBX: 00000007fffc445d RCX: 000000002548f071 [ 150.011841] RDX: 00000000ffff8881 RSI: 0000000000000001 RDI: ffff888125ed50d8 [ 150.022670] RBP: 0000000000000000 R08: 0000000000000000 R09: c0000000ffff7fff [ 150.033445] R10: ffffc9000f1ebb68 R11: ffffc9000f1ebb60 R12: 0000000000000000 [ 150.044204] R13: ffff888125ed50d8 R14: 0000000000000080 R15: 34cdc00034cdea80 [ 150.054963] FS: 0000000000000000(0000) GS:ffff88dfaf200000(0000) knlGS:0000000000000000 [ 150.066715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 150.076078] CR2: 00000007fffc445d CR3: 000000012448a006 CR4: 0000000000770ee0 [ 150.086887] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 150.097670] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 150.108323] PKRU: 55555554 [ 150.114690] Call Trace: [ 150.120497] ? printk+0x48/0x4a [ 150.127049] mpt3sas_scsih_issue_tm.cold.114+0x2e/0x2b3 [mpt3sas] [ 150.136453] mpt3sas_scsih_issue_locked_tm+0x86/0xb0 [mpt3sas] [ 150.145759] scsih_dev_reset+0xea/0x300 [mpt3sas] [ 150.153891] scsi_eh_ready_devs+0x541/0x9e0 [scsi_mod] [ 150.162206] ? __scsi_host_match+0x20/0x20 [scsi_mod] [ 150.170406] ? scsi_try_target_reset+0x90/0x90 [scsi_mod] [ 150.178925] ? blk_mq_tagset_busy_iter+0x45/0x60 [ 150.186638] ? scsi_try_target_reset+0x90/0x90 [scsi_mod] [ 150.195087] scsi_error_handler+0x3a5/0x4a0 [scsi_mod] [ 150.203206] ? __schedule+0x1e9/0x610 [ 150.209783] ? scsi_eh_get_sense+0x210/0x210 [scsi_mod] [ 150.217924] kthread+0x12e/0x150 [ 150.224041] ? kthread_worker_fn+0x130/0x130 [ 150.231206] ret_from_fork+0x1f/0x30 This is caused by mpt3sas_base_sync_reply_irqs() using an invalid reply_q pointer outside of the list_for_each_entry() loop. At the end of the full list traversal the pointer is invalid. Move the _base_process_reply_queue() call inside of the loop. CVE-2022-48835 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: Input: aiptek - properly check endpoint type Syzbot reported warning in usb_submit_urb() which is caused by wrong endpoint type. There was a check for the number of endpoints, but not for the type of endpoint. Fix it by replacing old desc.bNumEndpoints check with usb_find_common_endpoints() helper for finding endpoints Fail log: usb 5-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Workqueue: usb_hub_wq hub_event ... Call Trace: <TASK> aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830 input_open_device+0x1bb/0x320 drivers/input/input.c:629 kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593 CVE-2022-48836 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: gadget: rndis: prevent integer overflow in rndis_set_response() If "BufOffset" is very large the "BufOffset + 8" operation can have an integer overflow. CVE-2022-48837 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: gadget: Fix use-after-free bug by not setting udc->dev.driver The syzbot fuzzer found a use-after-free bug: BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320 Read of size 8 at addr ffff88802b934098 by task udevd/3689 CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 dev_uevent+0x712/0x780 drivers/base/core.c:2320 uevent_show+0x1b8/0x380 drivers/base/core.c:2391 dev_attr_show+0x4b/0x90 drivers/base/core.c:2094 Although the bug manifested in the driver core, the real cause was a race with the gadget core. dev_uevent() does: if (dev->driver) add_uevent_var(env, "DRIVER=%s", dev->driver->name); and between the test and the dereference of dev->driver, the gadget core sets dev->driver to NULL. The race wouldn't occur if the gadget core registered its devices on a real bus, using the standard synchronization techniques of the driver core. However, it's not necessary to make such a large change in order to fix this bug; all we need to do is make sure that udc->dev.driver is always NULL. In fact, there is no reason for udc->dev.driver ever to be set to anything, let alone to the value it currently gets: the address of the gadget's driver. After all, a gadget driver only knows how to manage a gadget, not how to manage a UDC. This patch simply removes the statements in the gadget core that touch udc->dev.driver. CVE-2022-48838 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: iavf: Fix hang during reboot/shutdown Recent commit 974578017fc1 ("iavf: Add waiting so the port is initialized in remove") adds a wait-loop at the beginning of iavf_remove() to ensure that port initialization is finished prior unregistering net device. This causes a regression in reboot/shutdown scenario because in this case callback iavf_shutdown() is called and this callback detaches the device, makes it down if it is running and sets its state to __IAVF_REMOVE. Later shutdown callback of associated PF driver (e.g. ice_shutdown) is called. That callback calls among other things sriov_disable() that calls indirectly iavf_remove() (see stack trace below). As the adapter state is already __IAVF_REMOVE then the mentioned loop is end-less and shutdown process hangs. The patch fixes this by checking adapter's state at the beginning of iavf_remove() and skips the rest of the function if the adapter is already in remove state (shutdown is in progress). Reproducer: 1. Create VF on PF driven by ice or i40e driver 2. Ensure that the VF is bound to iavf driver 3. Reboot [52625.981294] sysrq: SysRq : Show Blocked State [52625.988377] task:reboot state:D stack: 0 pid:17359 ppid: 1 f2 [52625.996732] Call Trace: [52625.999187] __schedule+0x2d1/0x830 [52626.007400] schedule+0x35/0xa0 [52626.010545] schedule_hrtimeout_range_clock+0x83/0x100 [52626.020046] usleep_range+0x5b/0x80 [52626.023540] iavf_remove+0x63/0x5b0 [iavf] [52626.027645] pci_device_remove+0x3b/0xc0 [52626.031572] device_release_driver_internal+0x103/0x1f0 [52626.036805] pci_stop_bus_device+0x72/0xa0 [52626.040904] pci_stop_and_remove_bus_device+0xe/0x20 [52626.045870] pci_iov_remove_virtfn+0xba/0x120 [52626.050232] sriov_disable+0x2f/0xe0 [52626.053813] ice_free_vfs+0x7c/0x340 [ice] [52626.057946] ice_remove+0x220/0x240 [ice] [52626.061967] ice_shutdown+0x16/0x50 [ice] [52626.065987] pci_device_shutdown+0x34/0x60 [52626.070086] device_shutdown+0x165/0x1c5 [52626.074011] kernel_restart+0xe/0x30 [52626.077593] __do_sys_reboot+0x1d2/0x210 [52626.093815] do_syscall_64+0x5b/0x1a0 [52626.097483] entry_SYSCALL_64_after_hwframe+0x65/0xca CVE-2022-48840 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL pointer dereference in ice_update_vsi_tx_ring_stats() It is possible to do NULL pointer dereference in routine that updates Tx ring stats. Currently only stats and bytes are updated when ring pointer is valid, but later on ring is accessed to propagate gathered Tx stats onto VSI stats. Change the existing logic to move to next ring when ring is NULL. CVE-2022-48841 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: ice: Fix race condition during interface enslave Commit 5dbbbd01cbba83 ("ice: Avoid RTNL lock when re-creating auxiliary device") changes a process of re-creation of aux device so ice_plug_aux_dev() is called from ice_service_task() context. This unfortunately opens a race window that can result in dead-lock when interface has left LAG and immediately enters LAG again. Reproducer: ``` #!/bin/sh ip link add lag0 type bond mode 1 miimon 100 ip link set lag0 for n in {1..10}; do echo Cycle: $n ip link set ens7f0 master lag0 sleep 1 ip link set ens7f0 nomaster done ``` This results in: [20976.208697] Workqueue: ice ice_service_task [ice] [20976.213422] Call Trace: [20976.215871] __schedule+0x2d1/0x830 [20976.219364] schedule+0x35/0xa0 [20976.222510] schedule_preempt_disabled+0xa/0x10 [20976.227043] __mutex_lock.isra.7+0x310/0x420 [20976.235071] enum_all_gids_of_dev_cb+0x1c/0x100 [ib_core] [20976.251215] ib_enum_roce_netdev+0xa4/0xe0 [ib_core] [20976.256192] ib_cache_setup_one+0x33/0xa0 [ib_core] [20976.261079] ib_register_device+0x40d/0x580 [ib_core] [20976.266139] irdma_ib_register_device+0x129/0x250 [irdma] [20976.281409] irdma_probe+0x2c1/0x360 [irdma] [20976.285691] auxiliary_bus_probe+0x45/0x70 [20976.289790] really_probe+0x1f2/0x480 [20976.298509] driver_probe_device+0x49/0xc0 [20976.302609] bus_for_each_drv+0x79/0xc0 [20976.306448] __device_attach+0xdc/0x160 [20976.310286] bus_probe_device+0x9d/0xb0 [20976.314128] device_add+0x43c/0x890 [20976.321287] __auxiliary_device_add+0x43/0x60 [20976.325644] ice_plug_aux_dev+0xb2/0x100 [ice] [20976.330109] ice_service_task+0xd0c/0xed0 [ice] [20976.342591] process_one_work+0x1a7/0x360 [20976.350536] worker_thread+0x30/0x390 [20976.358128] kthread+0x10a/0x120 [20976.365547] ret_from_fork+0x1f/0x40 ... [20976.438030] task:ip state:D stack: 0 pid:213658 ppid:213627 flags:0x00004084 [20976.446469] Call Trace: [20976.448921] __schedule+0x2d1/0x830 [20976.452414] schedule+0x35/0xa0 [20976.455559] schedule_preempt_disabled+0xa/0x10 [20976.460090] __mutex_lock.isra.7+0x310/0x420 [20976.464364] device_del+0x36/0x3c0 [20976.467772] ice_unplug_aux_dev+0x1a/0x40 [ice] [20976.472313] ice_lag_event_handler+0x2a2/0x520 [ice] [20976.477288] notifier_call_chain+0x47/0x70 [20976.481386] __netdev_upper_dev_link+0x18b/0x280 [20976.489845] bond_enslave+0xe05/0x1790 [bonding] [20976.494475] do_setlink+0x336/0xf50 [20976.502517] __rtnl_newlink+0x529/0x8b0 [20976.543441] rtnl_newlink+0x43/0x60 [20976.546934] rtnetlink_rcv_msg+0x2b1/0x360 [20976.559238] netlink_rcv_skb+0x4c/0x120 [20976.563079] netlink_unicast+0x196/0x230 [20976.567005] netlink_sendmsg+0x204/0x3d0 [20976.570930] sock_sendmsg+0x4c/0x50 [20976.574423] ____sys_sendmsg+0x1eb/0x250 [20976.586807] ___sys_sendmsg+0x7c/0xc0 [20976.606353] __sys_sendmsg+0x57/0xa0 [20976.609930] do_syscall_64+0x5b/0x1a0 [20976.613598] entry_SYSCALL_64_after_hwframe+0x65/0xca 1. Command 'ip link ... set nomaster' causes that ice_plug_aux_dev() is called from ice_service_task() context, aux device is created and associated device->lock is taken. 2. Command 'ip link ... set master...' calls ice's notifier under RTNL lock and that notifier calls ice_unplug_aux_dev(). That function tries to take aux device->lock but this is already taken by ice_plug_aux_dev() in step 1 3. Later ice_plug_aux_dev() tries to take RTNL lock but this is already taken in step 2 4. Dead-lock The patch fixes this issue by following changes: - Bit ICE_FLAG_PLUG_AUX_DEV is kept to be set during ice_plug_aux_dev() call in ice_service_task() - The bit is checked in ice_clear_rdma_cap() and only if it is not set then ice_unplug_aux_dev() is called. If it is set (in other words plugging of aux device was requested and ice_plug_aux_dev() is potentially running) then the function only clears the ---truncated--- CVE-2022-48842 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/vrr: Set VRR capable prop only if it is attached to connector VRR capable property is not attached by default to the connector It is attached only if VRR is supported. So if the driver tries to call drm core set prop function without it being attached that causes NULL dereference. CVE-2022-48843 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: bypass tiling flag check in virtual display case (v2) vkms leverages common amdgpu framebuffer creation, and also as it does not support FB modifier, there is no need to check tiling flags when initing framebuffer when virtual display is enabled. This can fix below calltrace: amdgpu 0000:00:08.0: GFX9+ requires FB check based on format modifier WARNING: CPU: 0 PID: 1023 at drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:1150 amdgpu_display_framebuffer_init+0x8e7/0xb40 [amdgpu] v2: check adev->enable_virtual_display instead as vkms can be enabled in bare metal as well. CVE-2022-48849 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: staging: gdm724x: fix use after free in gdm_lte_rx() The netif_rx_ni() function frees the skb so we can't dereference it to save the skb->len. CVE-2022-48851 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: gianfar: ethtool: Fix refcount leak in gfar_get_ts_info The of_find_compatible_node() function returns a node pointer with refcount incremented, We should use of_node_put() on it when done Add the missing of_node_put() to release the refcount. CVE-2022-48856 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: NFC: port100: fix use-after-free in port100_send_complete Syzbot reported UAF in port100_send_complete(). The root case is in missing usb_kill_urb() calls on error handling path of ->probe function. port100_send_complete() accesses devm allocated memory which will be freed on probe failure. We should kill this urbs before returning an error from probe function to prevent reported use-after-free Fail log: BUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935 Read of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26 ... Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935 __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670 ... Allocated by task 1255: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:436 [inline] ____kasan_kmalloc mm/kasan/common.c:515 [inline] ____kasan_kmalloc mm/kasan/common.c:474 [inline] __kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524 alloc_dr drivers/base/devres.c:116 [inline] devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823 devm_kzalloc include/linux/device.h:209 [inline] port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502 Freed by task 1255: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track+0x21/0x30 mm/kasan/common.c:45 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370 ____kasan_slab_free mm/kasan/common.c:366 [inline] ____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328 kasan_slab_free include/linux/kasan.h:236 [inline] __cache_free mm/slab.c:3437 [inline] kfree+0xf8/0x2b0 mm/slab.c:3794 release_nodes+0x112/0x1a0 drivers/base/devres.c:501 devres_release_all+0x114/0x190 drivers/base/devres.c:530 really_probe+0x626/0xcc0 drivers/base/dd.c:670 CVE-2022-48857 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix a race on command flush flow Fix a refcount use after free warning due to a race on command entry. Such race occurs when one of the commands releases its last refcount and frees its index and entry while another process running command flush flow takes refcount to this command entry. The process which handles commands flush may see this command as needed to be flushed if the other process released its refcount but didn't release the index yet. Fix it by adding the needed spin lock. It fixes the following warning trace: refcount_t: addition on 0; use-after-free. WARNING: CPU: 11 PID: 540311 at lib/refcount.c:25 refcount_warn_saturate+0x80/0xe0 ... RIP: 0010:refcount_warn_saturate+0x80/0xe0 ... Call Trace: <TASK> mlx5_cmd_trigger_completions+0x293/0x340 [mlx5_core] mlx5_cmd_flush+0x3a/0xf0 [mlx5_core] enter_error_state+0x44/0x80 [mlx5_core] mlx5_fw_fatal_reporter_err_work+0x37/0xe0 [mlx5_core] process_one_work+0x1be/0x390 worker_thread+0x4d/0x3d0 ? rescuer_thread+0x350/0x350 kthread+0x141/0x160 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x1f/0x30 </TASK> CVE-2022-48858 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: Add missing of_node_put() in prestera_switch_set_base_mac_addr This node pointer is returned by of_find_compatible_node() with refcount incremented. Calling of_node_put() to aovid the refcount leak. CVE-2022-48859 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: ethernet: Fix error handling in xemaclite_of_probe This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak. As the remove function do. CVE-2022-48860 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: vdpa: fix use-after-free on vp_vdpa_remove When vp_vdpa driver is unbind, vp_vdpa is freed in vdpa_unregister_device and then vp_vdpa->mdev.pci_dev is dereferenced in vp_modern_remove, triggering use-after-free. Call Trace of unbinding driver free vp_vdpa : do_syscall_64 vfs_write kernfs_fop_write_iter device_release_driver_internal pci_device_remove vp_vdpa_remove vdpa_unregister_device kobject_release device_release kfree Call Trace of dereference vp_vdpa->mdev.pci_dev: vp_modern_remove pci_release_selected_regions pci_release_region pci_resource_len pci_resource_end (dev)->resource[(bar)].end CVE-2022-48861 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: vhost: fix hung thread due to erroneous iotlb entries In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when start is 0 and last is ULONG_MAX. One instance where it can happen is when userspace sends an IOTLB message with iova=size=uaddr=0 (vhost_process_iotlb_msg). So, an entry with size = 0, start = 0, last = ULONG_MAX ends up in the iotlb. Next time a packet is sent, iotlb_access_ok() loops indefinitely due to that erroneous entry. Call Trace: <TASK> iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340 vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366 vhost_transport_do_send_pkt+0xe0/0xfd0 drivers/vhost/vsock.c:104 vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372 kthread+0x2e9/0x3a0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> Reported by syzbot at: https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87 To fix this, do two things: 1. Return -EINVAL in vhost_chr_write_iter() when userspace asks to map a range with size 0. 2. Fix vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX] by splitting it into two entries. CVE-2022-48862 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: mISDN: Fix memory leak in dsp_pipeline_build() dsp_pipeline_build() allocates dup pointer by kstrdup(cfg), but then it updates dup variable by strsep(&dup, "|"). As a result when it calls kfree(dup), the dup variable contains NULL. Found by Linux Driver Verification project (linuxtesting.org) with SVACE. CVE-2022-48863 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: HID: hid-thrustmaster: fix OOB read in thrustmaster_interrupts Syzbot reported an slab-out-of-bounds Read in thrustmaster_probe() bug. The root case is in missing validation check of actual number of endpoints. Code should not blindly access usb_host_interface::endpoint array, since it may contain less endpoints than code expects. Fix it by adding missing validaion check and print an error if number of endpoints do not match expected number CVE-2022-48866 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important A race problem was found in fs/proc/task_mmu.c in the memory management sub-component in the Linux kernel. This issue may allow a local attacker with user privilege to cause a denial of service. CVE-2023-1582 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate An issue was discovered in the USB subsystem in the Linux kernel through 6.4.2. There is an out-of-bounds and crash in read_descriptors in drivers/usb/core/sysfs.c. CVE-2023-37453 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate OpenTelemetry-Go Contrib is a collection of third-party packages for OpenTelemetry-Go. A handler wrapper out of the box adds labels `http.user_agent` and `http.method` that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent to it. HTTP header User-Agent or HTTP method for requests can be easily set by an attacker to be random and long. The library internally uses `httpconv.ServerRequest` that records every value for HTTP `method` and `User-Agent`. In order to be affected, a program has to use the `otelhttp.NewHandler` wrapper and not filter any unknown HTTP methods or User agents on the level of CDN, LB, previous middleware, etc. Version 0.44.0 fixed this issue when the values collected for attribute `http.request.method` were changed to be restricted to a set of well-known values and other high cardinality attributes were removed. As a workaround to stop being affected, `otelhttp.WithFilter()` can be used, but it requires manual careful configuration to not log certain requests entirely. For convenience and safe usage of this library, it should by default mark with the label `unknown` non-standard HTTP methods and User agents to show that such requests were made but do not increase cardinality. In case someone wants to stay with the current behavior, library API should allow to enable it. CVE-2023-45142 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:containerd-1.7.21-150000.117.1 important Qt 6 through 6.6 was discovered to contain a NULL pointer dereference via the function QXcbConnection::initializeAllAtoms(). NOTE: this is disputed because it is not expected that an X application should continue to run when there is arbitrary anomalous behavior from the X server. CVE-2023-45935 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libQt5Core5-5.15.2+kde294-150400.6.15.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libQt5DBus5-5.15.2+kde294-150400.6.15.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libQt5Gui5-5.15.2+kde294-150400.6.15.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libQt5Network5-5.15.2+kde294-150400.6.15.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libQt5Widgets5-5.15.2+kde294-150400.6.15.1 moderate OpenTelemetry-Go Contrib is a collection of third-party packages for OpenTelemetry-Go. Prior to version 0.46.0, the grpc Unary Server Interceptor out of the box adds labels `net.peer.sock.addr` and `net.peer.sock.port` that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent. An attacker can easily flood the peer address and port for requests. Version 0.46.0 contains a fix for this issue. As a workaround to stop being affected, a view removing the attributes can be used. The other possibility is to disable grpc metrics instrumentation by passing `otelgrpc.WithMeterProvider` option with `noop.NewMeterProvider`. CVE-2023-47108 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:containerd-1.7.21-150000.117.1 important An issue was discovered in the HTTP2 implementation in Qt before 5.15.17, 6.x before 6.2.11, 6.3.x through 6.5.x before 6.5.4, and 6.6.x before 6.6.2. network/access/http2/hpacktable.cpp has an incorrect HPack integer overflow check. CVE-2023-51714 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libQt5Core5-5.15.2+kde294-150400.6.15.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libQt5DBus5-5.15.2+kde294-150400.6.15.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libQt5Gui5-5.15.2+kde294-150400.6.15.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libQt5Network5-5.15.2+kde294-150400.6.15.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libQt5Widgets5-5.15.2+kde294-150400.6.15.1 moderate 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. CVE-2023-52591 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important In the Linux kernel, the following vulnerability has been resolved: virtio-blk: fix implicit overflow on virtio_max_dma_size The following codes have an implicit conversion from size_t to u32: (u32)max_size = (size_t)virtio_max_dma_size(vdev); This may lead overflow, Ex (size_t)4G -> (u32)0. Once virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX instead. CVE-2023-52762 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix UAF in svc_tcp_listen_data_ready() After the listener svc_sock is freed, and before invoking svc_tcp_accept() for the established child sock, there is a window that the newsock retaining a freed listener svc_sock in sk_user_data which cloning from parent. In the race window, if data is received on the newsock, we will observe use-after-free report in svc_tcp_listen_data_ready(). Reproduce by two tasks: 1. while :; do rpc.nfsd 0 ; rpc.nfsd; done 2. while :; do echo "" | ncat -4 127.0.0.1 2049 ; done KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc] Read of size 8 at addr ffff888139d96228 by task nc/102553 CPU: 7 PID: 102553 Comm: nc Not tainted 6.3.0+ #18 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <IRQ> dump_stack_lvl+0x33/0x50 print_address_description.constprop.0+0x27/0x310 print_report+0x3e/0x70 kasan_report+0xae/0xe0 svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc] tcp_data_queue+0x9f4/0x20e0 tcp_rcv_established+0x666/0x1f60 tcp_v4_do_rcv+0x51c/0x850 tcp_v4_rcv+0x23fc/0x2e80 ip_protocol_deliver_rcu+0x62/0x300 ip_local_deliver_finish+0x267/0x350 ip_local_deliver+0x18b/0x2d0 ip_rcv+0x2fb/0x370 __netif_receive_skb_one_core+0x166/0x1b0 process_backlog+0x24c/0x5e0 __napi_poll+0xa2/0x500 net_rx_action+0x854/0xc90 __do_softirq+0x1bb/0x5de do_softirq+0xcb/0x100 </IRQ> <TASK> ... </TASK> Allocated by task 102371: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x7b/0x90 svc_setup_socket+0x52/0x4f0 [sunrpc] svc_addsock+0x20d/0x400 [sunrpc] __write_ports_addfd+0x209/0x390 [nfsd] write_ports+0x239/0x2c0 [nfsd] nfsctl_transaction_write+0xac/0x110 [nfsd] vfs_write+0x1c3/0xae0 ksys_write+0xed/0x1c0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Freed by task 102551: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x190 __kmem_cache_free+0x133/0x270 svc_xprt_free+0x1e2/0x350 [sunrpc] svc_xprt_destroy_all+0x25a/0x440 [sunrpc] nfsd_put+0x125/0x240 [nfsd] nfsd_svc+0x2cb/0x3c0 [nfsd] write_threads+0x1ac/0x2a0 [nfsd] nfsctl_transaction_write+0xac/0x110 [nfsd] vfs_write+0x1c3/0xae0 ksys_write+0xed/0x1c0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Fix the UAF by simply doing nothing in svc_tcp_listen_data_ready() if state != TCP_LISTEN, that will avoid dereferencing svsk for all child socket. CVE-2023-52885 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important In affected libpcap versions during the setup of a remote packet capture the internal function sock_initaddress() calls getaddrinfo() and possibly freeaddrinfo(), but does not clearly indicate to the caller function whether freeaddrinfo() still remains to be called after the function returns. This makes it possible in some scenarios that both the function and its caller call freeaddrinfo() for the same allocated memory block. A similar problem was reported in Apple libpcap, to which Apple assigned CVE-2023-40400. CVE-2023-7256 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libpcap1-1.10.1-150400.3.3.2 moderate Resolver caches and authoritative zone databases that hold significant numbers of RRs for the same hostname (of any RTYPE) can suffer from degraded performance as content is being added or updated, and also when handling client queries for this name. This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.4-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1. CVE-2024-1737 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:bind-utils-9.16.50-150400.5.43.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:python3-bind-9.16.50-150400.5.43.1 important If a server hosts a zone containing a "KEY" Resource Record, or a resolver DNSSEC-validates a "KEY" Resource Record from a DNSSEC-signed domain in cache, a client can exhaust resolver CPU resources by sending a stream of SIG(0) signed requests. This issue affects BIND 9 versions 9.0.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.9.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.49-S1, and 9.18.11-S1 through 9.18.27-S1. CVE-2024-1975 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:bind-utils-9.16.50-150400.5.43.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:python3-bind-9.16.50-150400.5.43.1 important In the Linux kernel, the following vulnerability has been resolved: tls: fix race between async notify and socket close The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete() so any code past that point risks touching already freed data. Try to avoid the locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we are now tightly controlling when completion fires. CVE-2024-26583 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical. CVE-2024-26584 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important 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. CVE-2024-26585 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: tls: fix use-after-free on failed backlog decryption When the decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY, tls_do_decryption will wait until all async decryptions have completed. If one of them fails, tls_do_decryption will return -EBADMSG and tls_decrypt_sg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tls_decrypt_done. The only true async case is when crypto_aead_decrypt returns -EINPROGRESS. With -EBUSY, we already waited so we can tell tls_sw_recvmsg that the data is available for immediate copy, but we need to notify tls_decrypt_sg (via the new ->async_done flag) that the memory has already been released. CVE-2024-26800 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important In the Linux kernel, the following vulnerability has been resolved: vfio/platform: Create persistent IRQ handlers The vfio-platform SET_IRQS ioctl currently allows loopback triggering of an interrupt before a signaling eventfd has been configured by the user, which thereby allows a NULL pointer dereference. Rather than register the IRQ relative to a valid trigger, register all IRQs in a disabled state in the device open path. This allows mask operations on the IRQ to nest within the overall enable state governed by a valid eventfd signal. This decouples @masked, protected by the @locked spinlock from @trigger, protected via the @igate mutex. In doing so, it's guaranteed that changes to @trigger cannot race the IRQ handlers because the IRQ handler is synchronously disabled before modifying the trigger, and loopback triggering of the IRQ via ioctl is safe due to serialization with trigger changes via igate. For compatibility, request_irq() failures are maintained to be local to the SET_IRQS ioctl rather than a fatal error in the open device path. This allows, for example, a userspace driver with polling mode support to continue to work regardless of moving the request_irq() call site. This necessarily blocks all SET_IRQS access to the failed index. CVE-2024-26813 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: vfio/fsl-mc: Block calling interrupt handler without trigger The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between request_irq() and free_irq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive. The vfio-fsl-mc driver does not make use of irqfds, nor does it support any sort of masking operations, therefore unlike vfio-pci and vfio-platform, the flow can remain essentially unchanged. CVE-2024-26814 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: Always flush async #PF workqueue when vCPU is being destroyed Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM _module_ is put. Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes. Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will result in deadlock. async_pf_execute() can't return until kvm_put_kvm() finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes: WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Call Trace: <TASK> async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: <TASK> __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> If kvm_clear_async_pf_completion_queue() actually flushes the workqueue, then there's no need to gift async_pf_execute() a reference because all invocations of async_pf_execute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as __fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module. Note that kvm_check_async_pf_completion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. kvm_arch_async_page_present_queued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just: trace_kvm_async_pf_completed(addr, cr2_or_gpa); __kvm_vcpu_wake_up(vcpu); mmput(mm); and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables. Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue. Trying to flush a bogus workqueue entry rightly makes __flush_work() complain (kudos to whoever added that sanity check). Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al ---truncated--- CVE-2024-26976 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix Rx DMA datasize and skb_over_panic mana_get_rxbuf_cfg() aligns the RX buffer's DMA datasize to be multiple of 64. So a packet slightly bigger than mtu+14, say 1536, can be received and cause skb_over_panic. Sample dmesg: [ 5325.237162] skbuff: skb_over_panic: text:ffffffffc043277a len:1536 put:1536 head:ff1100018b517000 data:ff1100018b517100 tail:0x700 end:0x6ea dev:<NULL> [ 5325.243689] ------------[ cut here ]------------ [ 5325.245748] kernel BUG at net/core/skbuff.c:192! [ 5325.247838] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 5325.258374] RIP: 0010:skb_panic+0x4f/0x60 [ 5325.302941] Call Trace: [ 5325.304389] <IRQ> [ 5325.315794] ? skb_panic+0x4f/0x60 [ 5325.317457] ? asm_exc_invalid_op+0x1f/0x30 [ 5325.319490] ? skb_panic+0x4f/0x60 [ 5325.321161] skb_put+0x4e/0x50 [ 5325.322670] mana_poll+0x6fa/0xb50 [mana] [ 5325.324578] __napi_poll+0x33/0x1e0 [ 5325.326328] net_rx_action+0x12e/0x280 As discussed internally, this alignment is not necessary. To fix this bug, remove it from the code. So oversized packets will be marked as CQE_RX_TRUNCATED by NIC, and dropped. CVE-2024-35901 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate 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 <SF,VEC,EE,ME,IR,DR,RI,LE> 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 CVE-2024-36926 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate 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. CVE-2024-38559 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: 9p: add missing locking around taking dentry fid list Fix a use-after-free on dentry's d_fsdata fid list when a thread looks up a fid through dentry while another thread unlinks it: UAF thread: refcount_t: addition on 0; use-after-free. p9_fid_get linux/./include/net/9p/client.h:262 v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129 v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181 v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314 v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400 vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248 Freed by: p9_fid_destroy (inlined) p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456 p9_fid_put linux/./include/net/9p/client.h:278 v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55 v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518 vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335 The problem is that d_fsdata was not accessed under d_lock, because d_release() normally is only called once the dentry is otherwise no longer accessible but since we also call it explicitly in v9fs_remove that lock is required: move the hlist out of the dentry under lock then unref its fids once they are no longer accessible. CVE-2024-39463 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: ima: Fix use-after-free on a dentry's dname.name ->d_name.name can change on rename and the earlier value can be freed; there are conditions sufficient to stabilize it (->d_lock on dentry, ->d_lock on its parent, ->i_rwsem exclusive on the parent's inode, rename_lock), but none of those are met at any of the sites. Take a stable snapshot of the name instead. CVE-2024-39494 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important An issue was discovered in HTTP2 in Qt before 5.15.18, 6.x before 6.2.13, 6.3.x through 6.5.x before 6.5.7, and 6.6.x through 6.7.x before 6.7.3. Code to make security-relevant decisions about an established connection may execute too early, because the encrypted() signal has not yet been emitted and processed.. CVE-2024-39936 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libQt5Core5-5.15.2+kde294-150400.6.15.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libQt5DBus5-5.15.2+kde294-150400.6.15.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libQt5Gui5-5.15.2+kde294-150400.6.15.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libQt5Network5-5.15.2+kde294-150400.6.15.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libQt5Widgets5-5.15.2+kde294-150400.6.15.1 moderate Client queries that trigger serving stale data and that also require lookups in local authoritative zone data may result in an assertion failure. This issue affects BIND 9 versions 9.16.13 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.33-S1 through 9.11.37-S1, 9.16.13-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1. CVE-2024-4076 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:bind-utils-9.16.50-150400.5.43.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:python3-bind-9.16.50-150400.5.43.1 important In the Linux kernel, the following vulnerability has been resolved: jfs: xattr: fix buffer overflow for invalid xattr When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer. Fix this all up by properly restricting the size of the debug hex dump in the kernel log. CVE-2024-40902 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: gve: Clear napi->skb before dev_kfree_skb_any() gve_rx_free_skb incorrectly leaves napi->skb referencing an skb after it is freed with dev_kfree_skb_any(). This can result in a subsequent call to napi_get_frags returning a dangling pointer. Fix this by clearing napi->skb before the skb is freed. CVE-2024-40937 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important In the Linux kernel, the following vulnerability has been resolved: net: do not leave a dangling sk pointer, when socket creation fails It is possible to trigger a use-after-free by: * attaching an fentry probe to __sock_release() and the probe calling the bpf_get_socket_cookie() helper * running traceroute -I 1.1.1.1 on a freshly booted VM A KASAN enabled kernel will log something like below (decoded and stripped): ================================================================== BUG: KASAN: slab-use-after-free in __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) Read of size 8 at addr ffff888007110dd8 by task traceroute/299 CPU: 2 PID: 299 Comm: traceroute Tainted: G E 6.10.0-rc2+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1)) print_report (mm/kasan/report.c:378 mm/kasan/report.c:488) ? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) kasan_report (mm/kasan/report.c:603) ? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) kasan_check_range (mm/kasan/generic.c:183 mm/kasan/generic.c:189) __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) bpf_get_socket_ptr_cookie (./arch/x86/include/asm/preempt.h:94 ./include/linux/sock_diag.h:42 net/core/filter.c:5094 net/core/filter.c:5092) bpf_prog_875642cf11f1d139___sock_release+0x6e/0x8e bpf_trampoline_6442506592+0x47/0xaf __sock_release (net/socket.c:652) __sock_create (net/socket.c:1601) ... Allocated by task 299 on cpu 2 at 78.328492s: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:68) __kasan_slab_alloc (mm/kasan/common.c:312 mm/kasan/common.c:338) kmem_cache_alloc_noprof (mm/slub.c:3941 mm/slub.c:4000 mm/slub.c:4007) sk_prot_alloc (net/core/sock.c:2075) sk_alloc (net/core/sock.c:2134) inet_create (net/ipv4/af_inet.c:327 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1572) __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) __x64_sys_socket (net/socket.c:1718) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Freed by task 299 on cpu 2 at 78.328502s: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:68) kasan_save_free_info (mm/kasan/generic.c:582) poison_slab_object (mm/kasan/common.c:242) __kasan_slab_free (mm/kasan/common.c:256) kmem_cache_free (mm/slub.c:4437 mm/slub.c:4511) __sk_destruct (net/core/sock.c:2117 net/core/sock.c:2208) inet_create (net/ipv4/af_inet.c:397 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1572) __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) __x64_sys_socket (net/socket.c:1718) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Fix this by clearing the struct socket reference in sk_common_release() to cover all protocol families create functions, which may already attached the reference to the sk object with sock_init_data(). CVE-2024-40954 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list Use list_for_each_entry_safe() to allow iterating through the list and deleting the entry in the iteration process. The descriptor is freed via idxd_desc_complete() and there's a slight chance may cause issue for the list iterator when the descriptor is reused by another thread without it being deleted from the list. CVE-2024-40956 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Disassociate vcpus from redistributor region on teardown When tearing down a redistributor region, make sure we don't have any dangling pointer to that region stored in a vcpu. CVE-2024-40989 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important In the Linux kernel, the following vulnerability has been resolved: ptp: fix integer overflow in max_vclocks_store On 32bit systems, the "4 * max" multiply can overflow. Use kcalloc() to do the allocation to prevent this. CVE-2024-40994 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: don't allow mapping the MMIO HDP page with large pages We don't get the right offset in that case. The GPU has an unused 4K area of the register BAR space into which you can remap registers. We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM. However, on systems with >4K pages, we end up exposing PAGE_SIZE of MMIO space. CVE-2024-41011 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important In the Linux kernel, the following vulnerability has been resolved: filelock: Remove locks reliably when fcntl/close race is detected When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. Separately, posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle). After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory. Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush(). CVE-2024-41012 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix uninit-value in copy_name [syzbot reported] BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160 sized_strscpy+0xc4/0x160 copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411 hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:3877 [inline] slab_alloc_node mm/slub.c:3918 [inline] kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065 kmalloc include/linux/slab.h:628 [inline] hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Fix] When allocating memory to strbuf, initialize memory to 0. CVE-2024-41059 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important In the Linux kernel, the following vulnerability has been resolved: ASoC: topology: Fix references to freed memory Most users after parsing a topology file, release memory used by it, so having pointer references directly into topology file contents is wrong. Use devm_kmemdup(), to allocate memory as needed. CVE-2024-41069 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important In the Linux kernel, the following vulnerability has been resolved: tap: add missing verification for short frame The cited commit missed to check against the validity of the frame length in the tap_get_user_xdp() path, which could cause a corrupted skb to be sent downstack. Even before the skb is transmitted, the tap_get_user_xdp()-->skb_set_network_header() may assume the size is more than ETH_HLEN. Once transmitted, this could either cause out-of-bound access beyond the actual length, or confuse the underlayer with incorrect or inconsistent header length in the skb metadata. In the alternative path, tap_get_user() already prohibits short frame which has the length less than Ethernet header size from being transmitted. This is to drop any frame shorter than the Ethernet header size just like how tap_get_user() does. CVE: CVE-2024-41090 CVE-2024-41090 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important In the Linux kernel, the following vulnerability has been resolved: net/dpaa2: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it. CVE-2024-42093 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate In the Linux kernel, the following vulnerability has been resolved: IB/core: Implement a limit on UMAD receive List The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow. To address this, we introduce a limit to the size of the list. After considering typical scenarios, such as OpenSM processing, which can handle approximately 100k packets per second, and the 1-second retry timeout for most packets, we set the list size limit to 200k. Packets received beyond this limit are dropped, assuming they are likely timed out by the time they are handled by user-space. Notably, packets queued on the receive list due to reasons like timed-out sends are preserved even when the list is full. CVE-2024-42145 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 important In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix scv instruction crash with kexec kexec on pseries disables AIL (reloc_on_exc), required for scv instruction support, before other CPUs have been shut down. This means they can execute scv instructions after AIL is disabled, which causes an interrupt at an unexpected entry location that crashes the kernel. Change the kexec sequence to disable AIL after other CPUs have been brought down. As a refresher, the real-mode scv interrupt vector is 0x17000, and the fixed-location head code probably couldn't easily deal with implementing such high addresses so it was just decided not to support that interrupt at all. CVE-2024-42230 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:cluster-md-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:dlm-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:gfs2-kmp-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:kernel-default-5.14.21-150400.24.128.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:ocfs2-kmp-default-5.14.21-150400.24.128.1 moderate runc is a CLI tool for spawning and running containers according to the OCI specification. runc 1.1.13 and earlier, as well as 1.2.0-rc2 and earlier, can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with `os.MkdirAll`. While this could be used to create empty files, existing files would not be truncated. An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack's scope but the exact scope of protection hasn't been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3. Some workarounds are available. Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual user on the host (such as with rootless containers that don't use `/etc/sub[ug]id`), this in practice means that an attacker would only be able to create inodes in world-writable directories. A strict enough SELinux or AppArmor policy could in principle also restrict the scope if a specific label is applied to the runc runtime, though neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested. CVE-2024-45310 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:runc-1.1.14-150000.70.1 low An issue was discovered in libexpat before 2.6.3. xmlparse.c does not reject a negative length for XML_ParseBuffer. CVE-2024-45490 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:expat-2.4.4-150400.3.22.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libexpat1-2.4.4-150400.3.22.1 moderate An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINT_MAX equals SIZE_MAX). CVE-2024-45491 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:expat-2.4.4-150400.3.22.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libexpat1-2.4.4-150400.3.22.1 moderate An issue was discovered in libexpat before 2.6.3. nextScaffoldPart in xmlparse.c can have an integer overflow for m_groupSize on 32-bit platforms (where UINT_MAX equals SIZE_MAX). CVE-2024-45492 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:expat-2.4.4-150400.3.22.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libexpat1-2.4.4-150400.3.22.1 moderate Issue summary: Calling the OpenSSL API function SSL_select_next_proto with an empty supported client protocols buffer may cause a crash or memory contents to be sent to the peer. Impact summary: A buffer overread can have a range of potential consequences such as unexpected application beahviour or a crash. In particular this issue could result in up to 255 bytes of arbitrary private data from memory being sent to the peer leading to a loss of confidentiality. However, only applications that directly call the SSL_select_next_proto function with a 0 length list of supported client protocols are affected by this issue. This would normally never be a valid scenario and is typically not under attacker control but may occur by accident in the case of a configuration or programming error in the calling application. The OpenSSL API function SSL_select_next_proto is typically used by TLS applications that support ALPN (Application Layer Protocol Negotiation) or NPN (Next Protocol Negotiation). NPN is older, was never standardised and is deprecated in favour of ALPN. We believe that ALPN is significantly more widely deployed than NPN. The SSL_select_next_proto function accepts a list of protocols from the server and a list of protocols from the client and returns the first protocol that appears in the server list that also appears in the client list. In the case of no overlap between the two lists it returns the first item in the client list. In either case it will signal whether an overlap between the two lists was found. In the case where SSL_select_next_proto is called with a zero length client list it fails to notice this condition and returns the memory immediately following the client list pointer (and reports that there was no overlap in the lists). This function is typically called from a server side application callback for ALPN or a client side application callback for NPN. In the case of ALPN the list of protocols supplied by the client is guaranteed by libssl to never be zero in length. The list of server protocols comes from the application and should never normally be expected to be of zero length. In this case if the SSL_select_next_proto function has been called as expected (with the list supplied by the client passed in the client/client_len parameters), then the application will not be vulnerable to this issue. If the application has accidentally been configured with a zero length server list, and has accidentally passed that zero length server list in the client/client_len parameters, and has additionally failed to correctly handle a "no overlap" response (which would normally result in a handshake failure in ALPN) then it will be vulnerable to this problem. In the case of NPN, the protocol permits the client to opportunistically select a protocol when there is no overlap. OpenSSL returns the first client protocol in the no overlap case in support of this. The list of client protocols comes from the application and should never normally be expected to be of zero length. However if the SSL_select_next_proto function is accidentally called with a client_len of 0 then an invalid memory pointer will be returned instead. If the application uses this output as the opportunistic protocol then the loss of confidentiality will occur. This issue has been assessed as Low severity because applications are most likely to be vulnerable if they are using NPN instead of ALPN - but NPN is not widely used. It also requires an application configuration or programming error. Finally, this issue would not typically be under attacker control making active exploitation unlikely. The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue. Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. CVE-2024-5535 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libopenssl1_1-1.1.1l-150400.7.72.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:openssl-1_1-1.1.1l-150400.7.72.1 moderate A vulnerability in the package_index module of pypa/setuptools versions up to 69.1.1 allows for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. The issue is fixed in version 70.0. CVE-2024-6345 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:python3-setuptools-44.1.1-150400.9.9.1 important A null pointer dereference flaw was found in Libtiff via `tif_dirinfo.c`. This issue may allow an attacker to trigger memory allocation failures through certain means, such as restricting the heap space size or injecting faults, causing a segmentation fault. This can cause an application crash, eventually leading to a denial of service. CVE-2024-7006 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libtiff5-4.0.9-150000.45.47.1 moderate libcurl's ASN1 parser code has the `GTime2str()` function, used for parsing an ASN.1 Generalized Time field. If given an syntactically incorrect field, the parser might end up using -1 for the length of the *time fraction*, leading to a `strlen()` getting performed on a pointer to a heap buffer area that is not (purposely) null terminated. This flaw most likely leads to a crash, but can also lead to heap contents getting returned to the application when [CURLINFO_CERTINFO](https://curl.se/libcurl/c/CURLINFO_CERTINFO.html) is used. CVE-2024-7264 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:curl-8.0.1-150400.5.50.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libcurl4-8.0.1-150400.5.50.1 moderate Remote packet capture support is disabled by default in libpcap. When a user builds libpcap with remote packet capture support enabled, one of the functions that become available is pcap_findalldevs_ex(). One of the function arguments can be a filesystem path, which normally means a directory with input data files. When the specified path cannot be used as a directory, the function receives NULL from opendir(), but does not check the return value and passes the NULL value to readdir(), which causes a NULL pointer derefence. CVE-2024-8006 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libpcap1-1.10.1-150400.3.3.2 moderate When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine. If the returned status reports another error than 'revoked' (like for example 'unauthorized') it is not treated as a bad certficate. CVE-2024-8096 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:curl-8.0.1-150400.5.50.1 Public Cloud Image google/sles-15-sp4-sap-byos-v20240913-x86-64:libcurl4-8.0.1-150400.5.50.1 moderate