SUSE-IU-2025:643-1 SUSE Image security@suse.de SUSE Security Team SUSE Image SUSE-IU-2025:643-1 Interim 1 1 2025-11-19T17:01:38Z current 2025-02-21T01:00:00Z 2025-02-21T01:00:00Z cve-database/bin/generate-cvrf-publiccloud.pl 2021-02-18T01:00:00Z Image update for SUSE-IU-2025:643-1 / google/sles-15-sp4-sap-v20250221-x86-64 This image update for google/sles-15-sp4-sap-v20250221-x86-64 contains the following changes: Package 000release-packages:SLES_SAP-release was updated: Package bind was updated: - Limit additional section processing for large RDATA sets. When answering queries, don’t add data to the additional section if the answer has more than 13 names in the RDATA. This limits the number of lookups into the database(s) during a single client query, reducing the query-processing load. (CVE-2024-11187) [bsc#1236596, bind-9.16-CVE-2024-11187.patch] Package cloud-regionsrv-client was updated: - Update to 10.3.11 (bsc#1234050) + Send registration code for the extensions, not only base product - Update to 10.3.8 (bsc#1233333) + Fix the package requirements for cloud-regionsrv-client + Follow changes to suseconnect error reporting from stdout to stderr Package kernel-default was updated: - media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format (CVE-2024-53104 bsc#1234025). - commit a0c98f3 - Fix sorting error ``` Error: Current series.conf is not sorted. Please run series_sort.py first and commit the result before adding new patches. ``` - commit a81b3e9 - kABI fix for net: defer final 'struct net' free in netns dismantle (CVE-2024-56658 bsc#1235441). Upstream commit 0f6ede9fbc74 (&quot;net: defer final 'struct net' free in netns dismantle&quot;) introduced a new struct element `defer_free_list` into `struct net`. In order to preserve the kABI, move the newly added element into a hole. ``` struct netns_nexthop nexthop; /* 560 72 */ /* XXX 8 bytes hole, try to pack */ /* --- cacheline 10 boundary (640 bytes) --- */ struct netns_ipv4 ipv4 __attribute__((__aligned__(64))); /* 640 704 */ ``` - commit 3fc1183 - net: defer final 'struct net' free in netns dismantle (CVE-2024-56658 bsc#1235441). - commit 8694248 - NFS: Trigger the &quot;ls -l&quot; readdir heuristic sooner (bsc#1231847). - commit eadd17e - NFS: Improve heuristic for readdirplus (bsc#1231847). - commit ea10ca2 - NFS: Adjust the amount of readahead performed by NFS readdir (bsc#1231847). - commit ec8e677 - NFS: Do not flush the readdir cache in nfs_dentry_iput() (bsc#1231847). - commit ac72a63 - smb: prevent use-after-free due to open_cached_dir error paths (CVE-2024-53177 bsc#1234896). - commit 43156cd - net: inet6: do not leave a dangling sk pointer in inet6_create() (CVE-2024-56600 bsc#1235217). - commit 4f3d37a - blacklist.conf: Not affected byy CVE-2024-44932 and CVE-2024-44964 - Delete patches.suse/idpf-fix-UAFs-when-destroying-the-queues.patch. - Delete patches.suse/idpf-fix-memory-leaks-and-crashes-while-performing-a.patch. This fixes bsc#1236628 - commit 6ceedf0 - netfilter: x_tables: fix LED ID check in led_tg_check() (CVE-2024-56650 bsc#1235430). - commit a130a9c - drm/amdkfd: Correct the migration DMA map direction (bsc#1235969 CVE-2024-57897) - commit e14ed1e - Refresh patches.suse/drm-dp_mst-Ensure-mst_primary-pointer-is-valid-in-dr.patch. Fix warning by removing unused label out_put_primary - commit 354b3cb - Update patches.suse/tipc-fix-NULL-deref-in-cleanup_bearer.patch (bsc#1235433 CVE-2024-56661 bsc#1234931). - commit cb91989 - Update patches.suse/Bluetooth-hci_event-Align-BR-EDR-JUST_WORKS-paring-w.patch (git-fixes bsc#1230697 CVE-2024-8805 CVE-2024-53144 bsc#1234690). - commit ea9bf7d - net: inet: do not leave a dangling sk pointer in inet_create() (CVE-2024-56601 bsc#1235230). - commit b4769c0 - btrfs: fix use-after-free when COWing tree bock and tracing is enabled (bsc#1235645 CVE-2024-56759). - commit e811c1c - scsi: qla2xxx: Fix use after free on unload (CVE-2024-56623 bsc#1235466). - block, bfq: fix bfqq uaf in bfq_limit_depth() (CVE-2024-53166 bsc#1234884). - commit 894e940 - Refresh patches.suse/x86-xen-don-t-do-PV-iret-hypercall-through-hypercall.patch. - commit df281af - x86/static-call: Remove early_boot_irqs_disabled check to fix Xen PVH dom0 (git-fixes). - commit 2c0880a - ALSA: seq: oss: Fix races at processing SysEx messages (CVE-2024-57893 bsc#1235920). - commit f05049d - drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req() (CVE-2024-57798 bsc#1235818). - commit bfdad42 - drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req() (CVE-2024-57798 bsc#1235818). - commit 15490f2 - net/smc: check return value of sock_recvmsg when draining clc data (CVE-2024-57791 bsc#1235759). - commit b879d55 - power: supply: gpio-charger: Fix set charge current limits (git-fixes CVE-2024-57792 bsc#1235764). - commit 80ed527 - bpf, sockmap: Fix race between element replace and close() (CVE-2024-56664 bsc#1235249). - commit 03e2626 - s390/cpum_sf: Handle CPU hotplug remove during sampling (CVE-2024-57849 bsc#1235814). - commit e03f9af - Update patches.suse/smb-client-fix-TCP-timers-deadlock-after-rmmod.patch (CVE-2024-53095 bsc#1233642 CVE-2024-54680 bsc#1235723). - commit 6deb1aa - mm/swapfile: skip HugeTLB pages for unuse_vma (CVE-2024-50199 bsc#1233112). - commit 63ec06b - tipc: fix NULL deref in cleanup_bearer() (bsc#1235433). - commit a0043a3 - scsi: sg: Fix slab-use-after-free read in sg_release() (CVE-2024-56631 bsc#1235480). - commit 9399f03 - 9p/xen: fix release of IRQ (CVE-2024-56704 bsc#1235584). - commit 614e74c - net: ieee802154: do not leave a dangling sk pointer in ieee802154_create() (CVE-2024-56602 bsc#1235521). - commit 4049cc5 - net: hsr: avoid potential out-of-bound access in fill_frame_info() (CVE-2024-56648 bsc#1235451). - commit 0a88cb0 - ovl: Filter invalid inodes with missing lookup function (bsc#1235035 CVE-2024-56570). - commit 54169ab - NFSv4.0: Fix a use-after-free problem in the asynchronous open() (CVE-2024-53173 bsc#1234891). - commit f801b5b - tipc: Fix use-after-free of kernel socket in cleanup_bearer() (CVE-2024-56642 bsc#1235433). - commit ec9cc8d - can: j1939: j1939_session_new(): fix skb reference counting (CVE-2024-56645 bsc#1235134). - commit 5011af1 - Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create() (CVE-2024-56605 bsc#1235061). - commit c461209 - idpf: trigger SW interrupt when exiting wb_on_itr mode (bsc#1235507). - idpf: add support for SW triggered interrupts (bsc#1235507). - net: mana: Increase the DEF_RX_BUFFERS_PER_QUEUE to 1024 (bsc#1235246). - idpf: enable WB_ON_ITR (bsc#1235507). - commit 3cbddc0 - smb: client: fix use-after-free of signing key (CVE-2024-53179 bsc#1234921). - commit 86400c7 - smb: client: fix TCP timers deadlock after rmmod (git-fixes) [hcarvalho: this fixes issue discussed in bsc#1233642]. - commit 3e3e1af - smb: client: Fix use-after-free of network namespace (CVE-2024-53095 bsc#1233642). [hcarvalho: remove netfs_tracker_* related code because we don't have such infrastructure.] - commit 97b2d9e - wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan() (CVE-2024-56539 bsc#1234963). - commit e27d4b2 - vfio/pci: Properly hide first-in-list PCIe extended capability (bsc#1235004 CVE-2024-53214). - commit f520125 - Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc() (bsc#1235056 CVE-2024-56604). - commit cf32d9d - Bluetooth: Consolidate code around sk_alloc into a helper function (bsc#1235056 CVE-2024-56604). Refresh patches.suse/Bluetooth-SCO-Fix-UAF-on-sco_sock_timeout.patch. - commit 4de890e - nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry() (bsc#1235224 CVE-2024-56619). - commit b3f788e - jfs: array-index-out-of-bounds fix in dtReadFirst (bsc#1235220 CVE-2024-56598). - commit 4762f9a - hfsplus: don't query the device logical block size multiple times (bsc#1235073 CVE-2024-56548). - commit 67473c2 - wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service() (CVE-2024-53156 bsc#1234846). - commit 747e664 - ALSA: 6fire: Release resources at card release (CVE-2024-53239 bsc#1235054). - commit 6995b0a - NFSD: Prevent a potential integer overflow (CVE-2024-53146 bsc#1234853). - commit 79b751c - Update patches.suse/tcp-Fix-use-after-free-of-nreq-in-reqsk_timer_handler.patch (CVE-2024-50154 bsc#1233070 CVE-2024-53206 bsc#1234960). - commit cdf9cb8 - Update patches.suse/media-s5p_cec-limit-msg.len-to-CEC_MAX_MSG_SIZE.patch (git-fixes CVE-2022-49035 bsc#1215304). - commit d91bb81 - x86/xen: use new hypercall functions instead of hypercall page (XSA-466 CVE-2024-53241 bsc#1234282). - commit 439afbb - x86/xen: add central hypercall functions (XSA-466 CVE-2024-53241 bsc#1234282). - commit 1784c5e - x86/xen: don't do PV iret hypercall through hypercall page (XSA-466 CVE-2024-53241 bsc#1234282). - commit 9f17f93 - x86/static-call: provide a way to do very early static-call updates (XSA-466 CVE-2024-53241 bsc#1234282). - Refresh patches.kabi/tracepoint-fix.patch. - commit 2e422a6 - objtool/x86: allow syscall instruction (XSA-466 CVE-2024-53241 bsc#1234282). - commit 1f61d5b - x86: make get_cpu_vendor() accessible from Xen code (XSA-466 CVE-2024-53241 bsc#1234282). - commit 4d90703 - xen/netfront: fix crash when removing device (XSA-465 CVE-2024-53240 bsc#1234281). - commit f11b367 - Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE (git-fixes, bsc#1230697, CVE-2024-8805). - commit cddc976 - Update patches.suse/initramfs-avoid-filename-buffer-overrun.patch (CVE-2024-53142 bsc#1232436). - commit 14f79ec - scsi: storvsc: Do not flag MAINTENANCE_IN return of SRB_STATUS_DATA_OVERRUN as an error (git-fixes). - commit fe5d084 Package containerd was updated: - Update to containerd v1.7.23. Upstream release notes: &lt;https://github.com/containerd/containerd/releases/tag/v1.7.23&gt; - Rebase patches: * 0001-BUILD-SLE12-revert-btrfs-depend-on-kernel-UAPI-inste.patch - Update to containerd v1.7.22. Upstream release notes: &lt;https://github.com/containerd/containerd/releases/tag/v1.7.22&gt; - Bump minimum Go version to 1.22. - Rebase patches: * 0001-BUILD-SLE12-revert-btrfs-depend-on-kernel-UAPI-inste.patch Package curl was updated: - Security fix: [bsc#1236590, CVE-2025-0725] * content_encoding: drop support for zlib before 1.2.0.4 * content_encoding: put the decomp buffers into the writer structs * Add curl-CVE-2025-0725.patch - Security fix: [bsc#1236588, CVE-2025-0167] * netrc: 'default' with no credentials is not a match * Add curl-CVE-2025-0167.patch Package dhcp was updated: - bsc#1192020: Add 'Requires(pre): group(nogroup)' to fix user creation in pre scriptlet for dhcp-server. Package findutils was updated: - do not crash when file system loop was encountered [bsc#1231472]- added patches fix https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=e5d6eb919b9 + findutils-avoid-crash-system-loop.patch - modified patches % findutils-xautofs.patch (p1) Package glibc was updated: - assert-message-allocation.patch: Fix underallocation of abort_msg_s struct (CVE-2025-0395, bsc#1236282, BZ #32582)) Package google-dracut-config was updated: - Update to 0.0.4 + Move dracut config files to usr/lib/ dir - Update to 0.0.3 + Add provides and conflicts on generic name dracut-instance-change-config - Update to 0.0.2 + Rename config for nvme for consistency + Add dracut build requirement + Add virtio_net, virtio_rng and idpf drivers Package google-guest-configs was updated: - Add ggc-no-dup-metasrv-entry.patch + Follow up to (bsc#1234289, bsc#1234293). Avoid duplicate entries for the metadata server in /etc/hosts - Update to version 20241205.00 (bsc#1234254, bsc#1234255) * Update google_set_multiqueue to configure vCPU ranges based on VM platform (#90) - from version 20241204.00 * Restore google_set_multiqueue changes for A3Ultra (#93) * Depend on networkd-dispatcher in Ubuntu (#94) - Include components to set hostname and /etc/hosts entries (bsc#1234289, bsc#1234293) * Add sysconfig and sysconfig-network to BuildRequires * Install google_set_hostname into %{_bindir} * Install google_up.sh into %{_sysconfdir}/sysconfig/network/scripts/ * Add code to add and remove POST_UP_SCRIPT=&quot;compat:suse:google_up.sh&quot; to /etc/sysconfig/network/ifcfg-eth0 in %post and %postun sections Package google-osconfig-agent was updated: - Update to version 20250115.01 (bsc#1236406, bsc#1236407) * Bump cloud.google.com/go/osconfig from 1.14.2 to 1.14.3 (#772) - from version 20250115.00 * Bump cloud.google.com/go/auth from 0.10.2 to 0.14.0 (#767) * Bump go.opentelemetry.io/otel from 1.32.0 to 1.33.0 (#771) * Bump google.golang.org/protobuf from 1.35.1 to 1.36.2 (#763) - from version 20250114.00 * Bump golang.org/x/time from 0.8.0 to 0.9.0 (#770) - from version 20250113.01 * Bump cloud.google.com/go/auth/oauth2adapt from 0.2.5 to 0.2.7 (#766) - from version 20250113.00 * Bump golang.org/x/net from 0.31.0 to 0.34.0 (#769) - from version 20250110.00 * Bump golang.org/x/crypto from 0.29.0 to 0.31.0 in the go_modules group (#760) * Bump cloud.google.com/go/longrunning from 0.6.2 to 0.6.3 (#744) - from version 20241218.00 * Scanners fixes (#720) * Bump cloud.google.com/go/storage from 1.46.0 to 1.47.0 (#736) * Bump go.opentelemetry.io/contrib/detectors/gcp from 1.29.0 to 1.32.0 (#730) * Bump go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp (#738) * Bump golang.org/x/net from 0.30.0 to 0.31.0 (#731) - from version 20241118.01 * Bump github.com/googleapis/gax-go/v2 from 2.13.0 to 2.14.0 (#737) - from version 20241118.00 * move example to appropriate directory (#740) - from version 20241115.00 * Replace sles-15-sp3-sap old deprecated image in e2e tests (#739) * Bump golang.org/x/time from 0.7.0 to 0.8.0 (#734) - from version 20241114.03 * Bump github.com/GoogleCloudPlatform/opentelemetry-operations-go/detectors/gcp (#735) - from version 20241114.02 * Bump go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc (#729) - from version 20241114.01 * Remove SLES-15-SP2-SAP from e2e tests and add the new SLES-15-SP6 (#733) * Bump golang.org/x/crypto from 0.28.0 to 0.29.0 (#728) * Bump go.opentelemetry.io/otel/sdk/metric from 1.30.0 to 1.32.0 (#727) - from version 20241114.00 * Add example to run exec script from the gcs bucket (#732) * Bump cel.dev/expr from 0.16.1 to 0.18.0 (#723) - from version 20241112.00 * Bump golang.org/x/oauth2 from 0.23.0 to 0.24.0 (#722) * Bump github.com/GoogleCloudPlatform/opentelemetry-operations-go/exporter/metric (#721) * Bump google.golang.org/grpc from 1.67.1 to 1.68.0 (#725) * Bump github.com/golang/glog from 1.2.2 to 1.2.3 (#715) * Bump google.golang.org/api from 0.203.0 to 0.205.0 (#716) - from version 20241107.01 * Bump github.com/envoyproxy/go-control-plane from 0.13.0 to 0.13.1 (#717) * Bump github.com/GoogleCloudPlatform/opentelemetry-operations-go/internal/resourcemapping (#718) * Bump cloud.google.com/go/auth from 0.10.0 to 0.10.1 (#719) - from version 20241107.00 * Bump cloud.google.com/go/logging from 1.11.0 to 1.12.0 (#709) * Bump cloud.google.com/go/iam from 1.2.1 to 1.2.2 (#710) * Bump cloud.google.com/go/storage from 1.43.0 to 1.46.0 (#713) * Bump cloud.google.com/go/osconfig from 1.14.1 to 1.14.2 (#708) * Bump cloud.google.com/go/auth/oauth2adapt from 0.2.4 to 0.2.5 (#712) - from version 20241106.00 * Update OWNERS (#714) - from version 20241029.01 * remove toolchain override (#706) * Bump go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp (#701) - from version 20241029.00 * Bump go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc (#702) - from version 20241028.00 * Bump cloud.google.com/go/longrunning from 0.6.0 to 0.6.2 (#705) - from version 20241017.00 * Add a new CloudBuild trigger config-file for auto updating the presubmit test container image on every new commit (#704) - from version 20241004.00 * Add new packagebuild presubmit that will use cloud-build (#694) - from version 20240927.00 * Third batch of dependencies upgrade (#690) - Bump the golang compiler version to 1.22.4 (bsc#1225974, CVE-2024-24790) Package grub2 was updated: - Security fixes for 2024 * 0001-misc-Implement-grub_strlcpy.patch - Fix CVE-2024-45781 (bsc#1233617) * 0002-fs-ufs-Fix-a-heap-OOB-write.patch - Fix CVE-2024-56737 (bsc#1234958) - Fix CVE-2024-45782 (bsc#1233615) * 0003-fs-hfs-Fix-stack-OOB-write-with-grub_strcpy.patch - Fix CVE-2024-45780 (bsc#1233614) * 0004-fs-tar-Integer-overflow-leads-to-heap-OOB-write.patch - Fix CVE-2024-45783 (bsc#1233616) * 0005-fs-hfsplus-Set-a-grub_errno-if-mount-fails.patch * 0006-kern-file-Ensure-file-data-is-set.patch * 0007-kern-file-Implement-filesystem-reference-counting.patch - Fix CVE-2025-0624 (bsc#1236316) * 0008-net-Fix-OOB-write-in-grub_net_search_config_file.patch - Fix CVE-2024-45774 (bsc#1233609) * 0009-video-readers-jpeg-Do-not-permit-duplicate-SOF0-mark.patch - Fix CVE-2024-45775 (bsc#1233610) * 0010-commands-extcmd-Missing-check-for-failed-allocation.patch - Fix CVE-2025-0622 (bsc#1236317) * 0011-commands-pgp-Unregister-the-check_signatures-hooks-o.patch - Fix CVE-2025-0622 (bsc#1236317) * 0012-normal-Remove-variables-hooks-on-module-unload.patch - Fix CVE-2025-0622 (bsc#1236317) * 0013-gettext-Remove-variables-hooks-on-module-unload.patch - Fix CVE-2024-45776 (bsc#1233612) * 0014-gettext-Integer-overflow-leads-to-heap-OOB-write-or-.patch - Fix CVE-2024-45777 (bsc#1233613) * 0015-gettext-Integer-overflow-leads-to-heap-OOB-write.patch - Fix CVE-2025-0690 (bsc#1237012) * 0016-commands-read-Fix-an-integer-overflow-when-supplying.patch - Fix CVE-2025-1118 (bsc#1237013) * 0017-commands-minicmd-Block-the-dump-command-in-lockdown-.patch - Fix CVE-2024-45778 (bsc#1233606) - Fix CVE-2024-45779 (bsc#1233608) * 0018-fs-bfs-Disable-under-lockdown.patch - Fix CVE-2025-0677 (bsc#1237002) - Fix CVE-2025-0684 (bsc#1237008) - Fix CVE-2025-0685 (bsc#1237009) - Fix CVE-2025-0686 (bsc#1237010) - Fix CVE-2025-0689 (bsc#1237011) * 0019-fs-Disable-many-filesystems-under-lockdown.patch - Fix CVE-2025-1125 (bsc#1237014) - Fix CVE-2025-0678 (bsc#1237006) * 0020-fs-Prevent-overflows-when-allocating-memory-for-arra.patch - Bump upstream SBAT generation to 5 Package open-iscsi was updated: - iscsid-clear-scanning-thread-pr_set_io_flusher-flag.patch: fix device discovery failure on systems with a large number of devices (bsc#1235606). - Fix issue with yast restarting the iscsid service without first restarting the iscsid socket, which upsets systemd (bsc#1206132). This is already fixed upstream. - Branched SLE-15-SP3 from Factory. No longer in sync with Tumbleweed. - Backported upstream commit, which sets 'safe_logout' and 'startup' in iscsid.conf, to address bsc#1207157 - Updated year in SPEC file Package krb5 was updated: - Prevent overflow when calculating ulog block size. An authenticated attacker can cause kadmind to write beyond the end of the mapped region for the iprop log file, likely causing a process crash; (CVE-2025-24528); (bsc#1236619). - Add patch 0014-Prevent-overflow-when-calculating-ulog-block-size.patch Package cryptsetup was updated: - luksFormat succeeds despite creating corrupt device [bsc#1234273] * Add a better warning if luksFormat ends with image without any space for data. * Print warning early if LUKS container is too small for activation. * Add patches: - cryptsetup-Add-a-better-warning-if-luksFormat-no-space-for-data.patch - cryptsetup-Print-warning-early-if-LUKS-container-is-too-small-for-activation.patch Package openssl-1_1 was updated: - Security fix: [bsc#1236136, CVE-2024-13176] * timing side-channel in the ECDSA signature computation * Add openssl-CVE-2024-13176.patch Package python3 was updated: - Add CVE-2025-0938-sq-brackets-domain-names.patch which disallows square brackets ([ and ]) in domain names for parsed URLs (bsc#1236705, CVE-2025-0938, gh#python/cpython#105704) Package libtasn1 was updated: - Security fix: [bsc#1236878, CVE-2024-12133] * Potential DoS in handling of numerous SEQUENCE OF or SET OF elements * Add libtasn1-CVE-2024-12133.patch Package libxml2 was updated: - security update- added patches fix CVE-2022-49043 [bsc#1236460], use-after-free in xmlXIncludeAddNode + libxml2-CVE-2022-49043.patch Package libzypp was updated: - Create '.keep_packages' in the package cache dir to enforce keeping downloaded packages of all repos cahed there (bsc#1232458) - version 17.35.19 (35) - Fix missing UID checks in repomanager workflow (fixes #603) - version 17.35.18 (35) - Move cmake config files to LIB_INSTALL_DIR/cmake/Zypp (fixes #28) - Fix 'zypper ps' when running in incus container (bsc#1229106) Should apply to lxc and lxd containers as well. - Re-enable 'rpm --runposttrans' usage for chrooted systems (bsc#1216091) - version 17.35.17 (35) Package lifecycle-data-sle-module-live-patching was updated: - Added data for 5_14_21-150400_24_133, 5_14_21-150400_24_136, 5_14_21-150400_24_141, 5_14_21-150400_24_144, 5_14_21-150500_55_80, 5_14_21-150500_55_83, 5_14_21-150500_55_88, 5_3_18-150200_24_203, 5_3_18-150200_24_206, 5_3_18-150200_24_209, 5_3_18-150200_24_212, 5_3_18-150300_59_174, 5_3_18-150300_59_179, 5_3_18-150300_59_182, 5_3_18-150300_59_185, 6_4_0-150600_23_22, 6_4_0-150600_23_25, 6_4_0-150600_23_30, +kernel-livepatch-5_14_21-150500_13_61-rt,*,+kernel-livepatch-5_14_21-150500_13_67-rt,*,+kernel-livepatch-5_14_21-150500_13_70-rt,*,+kernel-livepatch-5_14_21-150500_13_73-rt,*,+kernel-livepatch-5_14_21-150500_13_76-rt,*,+kernel-livepatch-6_4_0-150600_10_11-rt,*,+kernel-livepatch-6_4_0-150600_10_14-rt,*,+kernel-livepatch-6_4_0-150600_10_17-rt,*,+kernel-livepatch-6_4_0-150600_10_8-rt,*. (bsc#1020320) Package openssh was updated: - Backported patch to fix a MitM attack against OpenSSH's VerifyHostKeyDNS-enabled client (bsc#1237040, CVE-2025-26465): * fix-CVE-2025-26465.patch Package python-instance-billing-flavor-check was updated: - Version 0.1.2 (bsc#1234444) + Improve detection of IPv4 and IPv6 network setup and use appropriate IP version for access the update servers + Improve reliability of flavor detection. Try an update server multiple times to get an answer, if we hit timeouts return the value flavor value from a cahce file. - Version 0.1.1 (bsc#1235991, bsc#1235992) + Add time stamp to log - From version 0.1.0 + Doc improvements clarifying exit staus codes Package rsync was updated: - Bump protocol version to 32 - make it easier to show server is patched. * Add rsync-protocol-version-32.patch - Fix FLAG_GOT_DIR_FLIST collission with FLAG_HLINKED * Added rsync-fix-FLAG_GOT_DIR_FLIST.patch - Security update,CVE-2024-12747, bsc#1235475 race condition in handling symbolic links * Added rsync-CVE-2024-12747.patch - Security update, fix multiple vulnerabilities: * CVE-2024-12085, bsc#1234101 - Info Leak via uninitialized Stack contents defeats ASLR * CVE-2024-12086, bsc#1234102 - Server leaks arbitrary client files * CVE-2024-12087, bsc#1234103 - Server can make client write files outside of destination directory using symbolic links * CVE-2024-12088, bsc#1234104 - --safe-links Bypass * Added rsync-CVE-2024-12085.patch * Added rsync-CVE-2024-12086_01.patch * Added rsync-CVE-2024-12086_02.patch * Added rsync-CVE-2024-12086_03.patch * Added rsync-CVE-2024-12086_04.patch * Added rsync-CVE-2024-12087_01.patch * Added rsync-CVE-2024-12087_02.patch * Added rsync-CVE-2024-12088.patch * Added rsync-fix-compile-missing-my_alloc_ref.patch Package 000release-packages:sle-ha-release was updated: Package 000release-packages:sle-module-basesystem-release was updated: Package 000release-packages:sle-module-containers-release was updated: Package 000release-packages:sle-module-desktop-applications-release was updated: Package 000release-packages:sle-module-development-tools-release was updated: Package 000release-packages:sle-module-live-patching-release was updated: Package 000release-packages:sle-module-public-cloud-release was updated: Package 000release-packages:sle-module-python3-release was updated: Package 000release-packages:sle-module-sap-applications-release was updated: Package 000release-packages:sle-module-server-applications-release was updated: Package 000release-packages:sle-module-web-scripting-release was updated: Package supportutils-plugin-ha-sap was updated: - Update to version 0.0.7+git.1737125956.a7079fc: * Call saphana-check.sh if the script is available in /usr/lib/saphana-checks (SUSE package) or in /opt/sap/saphana-checks (SAP package) (jsc#PED-11748, jsc#PED-11747) * to support 'trento checks' on supportutils content collect additional information: /usr/sap/hostctrl/exe/saphostctrl -function Ping corosync-cmapctl -b su - &lt;SIDADM&gt; -c disp+work su - &lt;SIDADM&gt; -c 'sapcontrol -nr &lt;NR&gt; -function GetVersionInfo' ls -lA --time-style=long-iso /etc/polkit-1/rules.d/[0-9][0-9]-SAP[A-Z][A-Z0-9][A-Z0-9]-[0-9][0-9].rules content of files in /etc/products.d/ (jsc#PED-12000, jsc#PED-12001) * collect Netweaver version by 'sapcontrol -nr &lt;NR&gt; -function GetVersionInfo' * collect 'operation_mode' setting by 'python getParameter.py --key=global.ini/system_replication/operation_mode --sapcontrol=1' * some shellcheck cleanup * adaption to the new used supportconfig.rc - change requirements remove the long deprecated supportconfig-plugin-resource and supportconfig-plugin-tag and add instead 'Requires: supportutils' (bsc#1235145) Package wget was updated: - If wget for an http URL is redirected to a different site (hostname parts of URLs differ), then any &quot;Authenticate&quot; and &quot;Cookie&quot; header entries are discarded. [bsc#1185551, wget-do-not-propagate-credentials.patch, bsc#1230795, CVE-2021-31879] Package yast2-sap-ha was updated: - yast sap_ha should check if HDB is running on primary (bsc#1235773) Build in a check if the DB is running on both nodes. - 4.4.11 - #458 [doc] Issue in &quot;Constraints for SAPHanaSR-angi&quot; https://github.com/SUSE/suse-best-practices/issues/458 - 4.4.10 Package zypper was updated: - lr: show the repositories keep-packages flag (bsc#1232458) It is shown in the details view or by using -k,--keep-packages. In addition libyzpp supports to enforce keeping downloaded packages of all repos within a package cache by creating a '.keep_packages' file there. - version 1.14.81 - Try to refresh update repos first to have updated GPG keys on the fly (bsc#1234752) An update repo may contain a prolonged GPG key for the GA repo. Refreshing the update repo first updates a trusted key on the fly and avoids a 'key has expired' warning being issued when refreshing the GA repo. - Refresh: restore legacy behavior and suppress Exception reporting as non-root (bsc#1235636) - version 1.14.80 - info: Allow to query a specific version (jsc#PED-11268) To query for a specific version simply append &quot;-&lt;version&gt;&quot; or &quot;-&lt;version&gt;-&lt;release&gt;&quot; to the &quot;&lt;name&gt;&quot; pattern. Note that the edition part must always match exactly. - version 1.14.79 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-v20250221-x86-64/ Public Cloud Image Info https://www.suse.com/support/security/rating/ SUSE Security Ratings Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 augeas-1.12.0-150400.3.5.1 augeas-lenses-1.12.0-150400.3.5.1 bind-utils-9.16.50-150400.5.46.1 cloud-regionsrv-client-10.3.11-150300.13.19.1 cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.19.1 cluster-md-kmp-default-5.14.21-150400.24.150.1 containerd-1.7.23-150000.120.1 curl-8.0.1-150400.5.62.1 dhcp-4.3.6.P1-150000.6.22.1 dhcp-client-4.3.6.P1-150000.6.22.1 dlm-kmp-default-5.14.21-150400.24.150.1 findutils-4.8.0-150300.3.3.2 gfs2-kmp-default-5.14.21-150400.24.150.1 glibc-2.31-150300.92.1 glibc-32bit-2.31-150300.92.1 glibc-i18ndata-2.31-150300.92.1 glibc-locale-2.31-150300.92.1 glibc-locale-base-2.31-150300.92.1 google-dracut-config-0.0.4-150300.7.9.2 google-guest-configs-20241205.00-150400.13.17.1 google-osconfig-agent-20250115.01-150000.1.41.1 grub2-2.06-150400.11.55.2 grub2-i386-pc-2.06-150400.11.55.2 grub2-x86_64-efi-2.06-150400.11.55.2 iscsiuio-0.7.8.6-150400.39.11.2 kernel-default-5.14.21-150400.24.150.1 krb5-1.19.2-150400.3.15.1 krb5-client-1.19.2-150400.3.15.1 libaugeas0-1.12.0-150400.3.5.1 libcryptsetup12-2.4.3-150400.3.6.2 libcurl4-8.0.1-150400.5.62.1 libopeniscsiusr0_2_0-2.1.7-150400.39.11.2 libopenssl1_1-1.1.1l-150400.7.78.1 libpython3_6m1_0-3.6.15-150300.10.81.1 libtasn1-4.13-150000.4.11.1 libtasn1-6-4.13-150000.4.11.1 libxml2-2-2.9.14-150400.5.35.1 libxml2-tools-2.9.14-150400.5.35.1 libzypp-17.35.19-150400.3.110.1 lifecycle-data-sle-module-live-patching-15-150000.4.120.1 nscd-2.31-150300.92.1 ocfs2-kmp-default-5.14.21-150400.24.150.1 open-iscsi-2.1.7-150400.39.11.2 openssh-8.4p1-150300.3.42.1 openssh-clients-8.4p1-150300.3.42.1 openssh-common-8.4p1-150300.3.42.1 openssh-server-8.4p1-150300.3.42.1 openssl-1_1-1.1.1l-150400.7.78.1 python-instance-billing-flavor-check-0.1.2-150000.1.17.1 python3-3.6.15-150300.10.81.1 python3-base-3.6.15-150300.10.81.1 python3-bind-9.16.50-150400.5.46.1 python3-curses-3.6.15-150300.10.81.1 rsync-3.2.3-150400.3.20.1 supportutils-plugin-ha-sap-0.0.7+git.1737125956.a7079fc-150000.1.21.2 wget-1.20.3-150000.3.29.1 yast2-sap-ha-4.4.11-150400.13.20.2 zypper-1.14.81-150400.3.73.1 augeas-1.12.0-150400.3.5.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 augeas-lenses-1.12.0-150400.3.5.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 bind-utils-9.16.50-150400.5.46.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 cloud-regionsrv-client-10.3.11-150300.13.19.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 cloud-regionsrv-client-plugin-gce-1.0.0-150300.13.19.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 cluster-md-kmp-default-5.14.21-150400.24.150.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 containerd-1.7.23-150000.120.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 curl-8.0.1-150400.5.62.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 dhcp-4.3.6.P1-150000.6.22.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 dhcp-client-4.3.6.P1-150000.6.22.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 dlm-kmp-default-5.14.21-150400.24.150.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 findutils-4.8.0-150300.3.3.2 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 gfs2-kmp-default-5.14.21-150400.24.150.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 glibc-2.31-150300.92.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 glibc-32bit-2.31-150300.92.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 glibc-i18ndata-2.31-150300.92.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 glibc-locale-2.31-150300.92.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 glibc-locale-base-2.31-150300.92.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 google-dracut-config-0.0.4-150300.7.9.2 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 google-guest-configs-20241205.00-150400.13.17.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 google-osconfig-agent-20250115.01-150000.1.41.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 grub2-2.06-150400.11.55.2 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 grub2-i386-pc-2.06-150400.11.55.2 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 grub2-x86_64-efi-2.06-150400.11.55.2 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 iscsiuio-0.7.8.6-150400.39.11.2 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 kernel-default-5.14.21-150400.24.150.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 krb5-1.19.2-150400.3.15.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 krb5-client-1.19.2-150400.3.15.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 libaugeas0-1.12.0-150400.3.5.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 libcryptsetup12-2.4.3-150400.3.6.2 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 libcurl4-8.0.1-150400.5.62.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 libopeniscsiusr0_2_0-2.1.7-150400.39.11.2 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 libopenssl1_1-1.1.1l-150400.7.78.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 libpython3_6m1_0-3.6.15-150300.10.81.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 libtasn1-4.13-150000.4.11.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 libtasn1-6-4.13-150000.4.11.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 libxml2-2-2.9.14-150400.5.35.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 libxml2-tools-2.9.14-150400.5.35.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 libzypp-17.35.19-150400.3.110.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 lifecycle-data-sle-module-live-patching-15-150000.4.120.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 nscd-2.31-150300.92.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 ocfs2-kmp-default-5.14.21-150400.24.150.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 open-iscsi-2.1.7-150400.39.11.2 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 openssh-8.4p1-150300.3.42.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 openssh-clients-8.4p1-150300.3.42.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 openssh-common-8.4p1-150300.3.42.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 openssh-server-8.4p1-150300.3.42.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 openssl-1_1-1.1.1l-150400.7.78.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 python-instance-billing-flavor-check-0.1.2-150000.1.17.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 python3-3.6.15-150300.10.81.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 python3-base-3.6.15-150300.10.81.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 python3-bind-9.16.50-150400.5.46.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 python3-curses-3.6.15-150300.10.81.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 rsync-3.2.3-150400.3.20.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 supportutils-plugin-ha-sap-0.0.7+git.1737125956.a7079fc-150000.1.21.2 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 wget-1.20.3-150000.3.29.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 yast2-sap-ha-4.4.11-150400.13.20.2 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 zypper-1.14.81-150400.3.73.1 as a component of Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64 GNU Wget through 1.21.1 does not omit the Authorization header upon a redirect to a different origin, a related issue to CVE-2018-1000007. CVE-2021-31879 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:wget-1.20.3-150000.3.29.1 moderate 5.8 AV:N/AC:M/Au:N/C:P/I:P/A:N In the Linux kernel, the following vulnerability has been resolved: media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE I expect that the hardware will have limited this to 16, but just in case it hasn't, check for this corner case. CVE-2022-49035 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important xmlXIncludeAddNode in xinclude.c in libxml2 before 2.11.0 has a use-after-free. CVE-2022-49043 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:libxml2-2-2.9.14-150400.5.35.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:libxml2-tools-2.9.14-150400.5.35.1 important It is possible to construct a zone such that some queries to it will generate responses containing numerous records in the Additional section. An attacker sending many such queries can cause either the authoritative server itself or an independent resolver to use disproportionate resources processing the queries. Zones will usually need to have been deliberately crafted to attack this exposure. 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.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.32-S1. CVE-2024-11187 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:bind-utils-9.16.50-150400.5.46.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:python3-bind-9.16.50-150400.5.46.1 important A flaw was found in rsync which could be triggered when rsync compares file checksums. This flaw allows an attacker to manipulate the checksum length (s2length) to cause a comparison between a checksum and uninitialized memory and leak one byte of uninitialized stack data at a time. CVE-2024-12085 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:rsync-3.2.3-150400.3.20.1 moderate A flaw was found in rsync. It could allow a server to enumerate the contents of an arbitrary file from the client's machine. This issue occurs when files are being copied from a client to a server. During this process, the rsync server will send checksums of local data to the client to compare with in order to determine what data needs to be sent to the server. By sending specially constructed checksum values for arbitrary files, an attacker may be able to reconstruct the data of those files byte-by-byte based on the responses from the client. CVE-2024-12086 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:rsync-3.2.3-150400.3.20.1 moderate A path traversal vulnerability exists in rsync. It stems from behavior enabled by the `--inc-recursive` option, a default-enabled option for many client options and can be enabled by the server even if not explicitly enabled by the client. When using the `--inc-recursive` option, a lack of proper symlink verification coupled with deduplication checks occurring on a per-file-list basis could allow a server to write files outside of the client's intended destination directory. A malicious server could write malicious files to arbitrary locations named after valid directories/paths on the client. CVE-2024-12087 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:rsync-3.2.3-150400.3.20.1 important A flaw was found in rsync. When using the `--safe-links` option, the rsync client fails to properly verify if a symbolic link destination sent from the server contains another symbolic link within it. This results in a path traversal vulnerability, which may lead to arbitrary file write outside the desired directory. CVE-2024-12088 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:rsync-3.2.3-150400.3.20.1 moderate A flaw in libtasn1 causes inefficient handling of specific certificate data. When processing a large number of elements in a certificate, libtasn1 takes much longer than expected, which can slow down or even crash the system. This flaw allows an attacker to send a specially crafted certificate, causing a denial of service attack. CVE-2024-12133 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:libtasn1-4.13-150000.4.11.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:libtasn1-6-4.13-150000.4.11.1 important A flaw was found in rsync. This vulnerability arises from a race condition during rsync's handling of symbolic links. Rsync's default behavior when encountering symbolic links is to skip them. If an attacker replaced a regular file with a symbolic link at the right time, it was possible to bypass the default behavior and traverse symbolic links. Depending on the privileges of the rsync process, an attacker could leak sensitive information, potentially leading to privilege escalation. CVE-2024-12747 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:rsync-3.2.3-150400.3.20.1 moderate Issue summary: A timing side-channel which could potentially allow recovering the private key exists in the ECDSA signature computation. Impact summary: A timing side-channel in ECDSA signature computations could allow recovering the private key by an attacker. However, measuring the timing would require either local access to the signing application or a very fast network connection with low latency. There is a timing signal of around 300 nanoseconds when the top word of the inverted ECDSA nonce value is zero. This can happen with significant probability only for some of the supported elliptic curves. In particular the NIST P-521 curve is affected. To be able to measure this leak, the attacker process must either be located in the same physical computer or must have a very fast network connection with low latency. For that reason the severity of this vulnerability is Low. The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are affected by this issue. CVE-2024-13176 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:libopenssl1_1-1.1.1l-150400.7.78.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:openssl-1_1-1.1.1l-150400.7.78.1 moderate The various Is methods (IsPrivate, IsLoopback, etc) did not work as expected for IPv4-mapped IPv6 addresses, returning false for addresses which would return true in their traditional IPv4 forms. CVE-2024-24790 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:google-osconfig-agent-20250115.01-150000.1.41.1 moderate In the Linux kernel, the following vulnerability has been resolved: idpf: fix UAFs when destroying the queues The second tagged commit started sometimes (very rarely, but possible) throwing WARNs from net/core/page_pool.c:page_pool_disable_direct_recycling(). Turned out idpf frees interrupt vectors with embedded NAPIs *before* freeing the queues making page_pools' NAPI pointers lead to freed memory before these pools are destroyed by libeth. It's not clear whether there are other accesses to the freed vectors when destroying the queues, but anyway, we usually free queue/interrupt vectors only when the queues are destroyed and the NAPIs are guaranteed to not be referenced anywhere. Invert the allocation and freeing logic making queue/interrupt vectors be allocated first and freed last. Vectors don't require queues to be present, so this is safe. Additionally, this change allows to remove that useless queue->q_vector pointer cleanup, as vectors are still valid when freeing the queues (+ both are freed within one function, so it's not clear why nullify the pointers at all). CVE-2024-44932 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 moderate A flaw was found in grub2. A specially crafted JPEG file can cause the JPEG parser of grub2 to incorrectly check the bounds of its internal buffers, resulting in an out-of-bounds write. The possibility of overwriting sensitive information to bypass secure boot protections is not discarded. CVE-2024-45774 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate A flaw was found in grub2 where the grub_extcmd_dispatcher() function calls grub_arg_list_alloc() to allocate memory for the grub's argument list. However, it fails to check in case the memory allocation fails. Once the allocation fails, a NULL point will be processed by the parse_option() function, leading grub to crash or, in some rare scenarios, corrupt the IVT data. CVE-2024-45775 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate When reading the language .mo file in grub_mofile_open(), grub2 fails to verify an integer overflow when allocating its internal buffer. A crafted .mo file may lead the buffer size calculation to overflow, leading to out-of-bound reads and writes. This flaw allows an attacker to leak sensitive data or overwrite critical data, possibly circumventing secure boot protections. CVE-2024-45776 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate A flaw was found in grub2. The calculation of the translation buffer when reading a language .mo file in grub_gettext_getstr_from_position() may overflow, leading to a Out-of-bound write. This issue can be leveraged by an attacker to overwrite grub2's sensitive heap data, eventually leading to the circumvention of secure boot protections. CVE-2024-45777 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate A stack overflow flaw was found when reading a BFS file system. A crafted BFS filesystem may lead to an uncontrolled loop, causing grub2 to crash. CVE-2024-45778 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate An integer overflow flaw was found in the BFS file system driver in grub2. When reading a file with an indirect extent map, grub2 fails to validate the number of extent entries to be read. A crafted or corrupted BFS filesystem may cause an integer overflow during the file reading, leading to a heap of bounds read. As a consequence, sensitive data may be leaked, or grub2 will crash. CVE-2024-45779 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate A flaw was found in grub2. When reading tar files, grub2 allocates an internal buffer for the file name. However, it fails to properly verify the allocation against possible integer overflows. It's possible to cause the allocation length to overflow with a crafted tar file, leading to a heap out-of-bounds write. This flaw eventually allows an attacker to circumvent secure boot protections. CVE-2024-45780 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate A flaw was found in grub2. When reading a symbolic link's name from a UFS filesystem, grub2 fails to validate the string length taken as an input. The lack of validation may lead to a heap out-of-bounds write, causing data integrity issues and eventually allowing an attacker to circumvent secure boot protections. CVE-2024-45781 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate A flaw was found in the HFS filesystem. When reading an HFS volume's name at grub_fs_mount(), the HFS filesystem driver performs a strcpy() using the user-provided volume name as input without properly validating the volume name's length. This issue may read to a heap-based out-of-bounds writer, impacting grub's sensitive data integrity and eventually leading to a secure boot protection bypass. CVE-2024-45782 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate A flaw was found in grub2. When failing to mount an HFS+ grub, the hfsplus filesystem driver doesn't properly set an ERRNO value. This issue may lead to a NULL pointer access. CVE-2024-45783 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). """ We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. """ The commit 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb CVE-2024-50154 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it. CVE-2024-50199 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 moderate In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 ("smc: Fix use-after-free in tcp_write_timer_handler()."). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated--- CVE-2024-53095 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming. CVE-2024-53104 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar="A" # change to "\0" to properly zero terminate / pad magic="070701" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname="initramfs_test_fname_overrun" namelen=$(( ${#fname} + 1 )) # plus one to account for terminator printf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \ $magic $ino $mode $uid $gid $nlink $mtime $filesize \ $devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf "%.s${nilchar}" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset. CVE-2024-53142 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 moderate In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent a potential integer overflow If the tag length is >= U32_MAX - 3 then the "length + 4" addition can result in an integer overflow. Address this by splitting the decoding into several steps so that decode_cb_compound4res() does not have to perform arithmetic on the unsafe length value. CVE-2024-53146 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service() I found the following bug in my fuzzer: UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51 index 255 is out of range for type 'htc_endpoint [22]' CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events request_firmware_work_func Call Trace: <TASK> dump_stack_lvl+0x180/0x1b0 __ubsan_handle_out_of_bounds+0xd4/0x130 htc_issue_send.constprop.0+0x20c/0x230 ? _raw_spin_unlock_irqrestore+0x3c/0x70 ath9k_wmi_cmd+0x41d/0x610 ? mark_held_locks+0x9f/0xe0 ... Since this bug has been confirmed to be caused by insufficient verification of conn_rsp_epid, I think it would be appropriate to add a range check for conn_rsp_epid to htc_connect_service() to prevent the bug from occurring. CVE-2024-53156 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix bfqq uaf in bfq_limit_depth() Set new allocated bfqq to bic or remove freed bfqq from bic are both protected by bfqd->lock, however bfq_limit_depth() is deferencing bfqq from bic without the lock, this can lead to UAF if the io_context is shared by multiple tasks. For example, test bfq with io_uring can trigger following UAF in v6.6: ================================================================== BUG: KASAN: slab-use-after-free in bfqq_group+0x15/0x50 Call Trace: <TASK> dump_stack_lvl+0x47/0x80 print_address_description.constprop.0+0x66/0x300 print_report+0x3e/0x70 kasan_report+0xb4/0xf0 bfqq_group+0x15/0x50 bfqq_request_over_limit+0x130/0x9a0 bfq_limit_depth+0x1b5/0x480 __blk_mq_alloc_requests+0x2b5/0xa00 blk_mq_get_new_requests+0x11d/0x1d0 blk_mq_submit_bio+0x286/0xb00 submit_bio_noacct_nocheck+0x331/0x400 __block_write_full_folio+0x3d0/0x640 writepage_cb+0x3b/0xc0 write_cache_pages+0x254/0x6c0 write_cache_pages+0x254/0x6c0 do_writepages+0x192/0x310 filemap_fdatawrite_wbc+0x95/0xc0 __filemap_fdatawrite_range+0x99/0xd0 filemap_write_and_wait_range.part.0+0x4d/0xa0 blkdev_read_iter+0xef/0x1e0 io_read+0x1b6/0x8a0 io_issue_sqe+0x87/0x300 io_wq_submit_work+0xeb/0x390 io_worker_handle_work+0x24d/0x550 io_wq_worker+0x27f/0x6c0 ret_from_fork_asm+0x1b/0x30 </TASK> Allocated by task 808602: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_slab_alloc+0x83/0x90 kmem_cache_alloc_node+0x1b1/0x6d0 bfq_get_queue+0x138/0xfa0 bfq_get_bfqq_handle_split+0xe3/0x2c0 bfq_init_rq+0x196/0xbb0 bfq_insert_request.isra.0+0xb5/0x480 bfq_insert_requests+0x156/0x180 blk_mq_insert_request+0x15d/0x440 blk_mq_submit_bio+0x8a4/0xb00 submit_bio_noacct_nocheck+0x331/0x400 __blkdev_direct_IO_async+0x2dd/0x330 blkdev_write_iter+0x39a/0x450 io_write+0x22a/0x840 io_issue_sqe+0x87/0x300 io_wq_submit_work+0xeb/0x390 io_worker_handle_work+0x24d/0x550 io_wq_worker+0x27f/0x6c0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x1b/0x30 Freed by task 808589: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x27/0x40 __kasan_slab_free+0x126/0x1b0 kmem_cache_free+0x10c/0x750 bfq_put_queue+0x2dd/0x770 __bfq_insert_request.isra.0+0x155/0x7a0 bfq_insert_request.isra.0+0x122/0x480 bfq_insert_requests+0x156/0x180 blk_mq_dispatch_plug_list+0x528/0x7e0 blk_mq_flush_plug_list.part.0+0xe5/0x590 __blk_flush_plug+0x3b/0x90 blk_finish_plug+0x40/0x60 do_writepages+0x19d/0x310 filemap_fdatawrite_wbc+0x95/0xc0 __filemap_fdatawrite_range+0x99/0xd0 filemap_write_and_wait_range.part.0+0x4d/0xa0 blkdev_read_iter+0xef/0x1e0 io_read+0x1b6/0x8a0 io_issue_sqe+0x87/0x300 io_wq_submit_work+0xeb/0x390 io_worker_handle_work+0x24d/0x550 io_wq_worker+0x27f/0x6c0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x1b/0x30 Fix the problem by protecting bic_to_bfqq() with bfqd->lock. CVE-2024-53166 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: NFSv4.0: Fix a use-after-free problem in the asynchronous open() Yang Erkun reports that when two threads are opening files at the same time, and are forced to abort before a reply is seen, then the call to nfs_release_seqid() in nfs4_opendata_free() can result in a use-after-free of the pointer to the defunct rpc task of the other thread. The fix is to ensure that if the RPC call is aborted before the call to nfs_wait_on_sequence() is complete, then we must call nfs_release_seqid() in nfs4_open_release() before the rpc_task is freed. CVE-2024-53173 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: smb: prevent use-after-free due to open_cached_dir error paths If open_cached_dir() encounters an error parsing the lease from the server, the error handling may race with receiving a lease break, resulting in open_cached_dir() freeing the cfid while the queued work is pending. Update open_cached_dir() to drop refs rather than directly freeing the cfid. Have cached_dir_lease_break(), cfids_laundromat_worker(), and invalidate_all_cached_dirs() clear has_lease immediately while still holding cfids->cfid_list_lock, and then use this to also simplify the reference counting in cfids_laundromat_worker() and invalidate_all_cached_dirs(). Fixes this KASAN splat (which manually injects an error and lease break in open_cached_dir()): ================================================================== BUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0 Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65 CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Workqueue: cifsiod smb2_cached_lease_break Call Trace: <TASK> dump_stack_lvl+0x77/0xb0 print_report+0xce/0x660 kasan_report+0xd3/0x110 smb2_cached_lease_break+0x27/0xb0 process_one_work+0x50a/0xc50 worker_thread+0x2ba/0x530 kthread+0x17c/0x1c0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 open_cached_dir+0xa7d/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x51/0x70 kfree+0x174/0x520 open_cached_dir+0x97f/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Last potentially related work creation: kasan_save_stack+0x33/0x60 __kasan_record_aux_stack+0xad/0xc0 insert_work+0x32/0x100 __queue_work+0x5c9/0x870 queue_work_on+0x82/0x90 open_cached_dir+0x1369/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff88811cc24c00 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 16 bytes inside of freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000) CVE-2024-53177 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free of signing key Customers have reported use-after-free in @ses->auth_key.response with SMB2.1 + sign mounts which occurs due to following race: task A task B cifs_mount() dfs_mount_share() get_session() cifs_mount_get_session() cifs_send_recv() cifs_get_smb_ses() compound_send_recv() cifs_setup_session() smb2_setup_request() kfree_sensitive() smb2_calc_signature() crypto_shash_setkey() *UAF* Fix this by ensuring that we have a valid @ses->auth_key.response by checking whether @ses->ses_status is SES_GOOD or SES_EXITING with @ses->ses_lock held. After commit 24a9799aa8ef ("smb: client: fix UAF in smb2_reconnect_server()"), we made sure to call ->logoff() only when @ses was known to be good (e.g. valid ->auth_key.response), so it's safe to access signing key when @ses->ses_status == SES_EXITING. CVE-2024-53179 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Properly hide first-in-list PCIe extended capability There are cases where a PCIe extended capability should be hidden from the user. For example, an unknown capability (i.e., capability with ID greater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally chosen to be hidden from the user. Hiding a capability is done by virtualizing and modifying the 'Next Capability Offset' field of the previous capability so it points to the capability after the one that should be hidden. The special case where the first capability in the list should be hidden is handled differently because there is no previous capability that can be modified. In this case, the capability ID and version are zeroed while leaving the next pointer intact. This hides the capability and leaves an anchor for the rest of the capability list. However, today, hiding the first capability in the list is not done properly if the capability is unknown, as struct vfio_pci_core_device->pci_config_map is set to the capability ID during initialization but the capability ID is not properly checked later when used in vfio_config_do_rw(). This leads to the following warning [1] and to an out-of-bounds access to ecap_perms array. Fix it by checking cap_id in vfio_config_do_rw(), and if it is greater than PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct read only access instead of the ecap_perms array. Note that this is safe since the above is the only case where cap_id can exceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which are already checked before). [1] WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1 (snip) Call Trace: <TASK> ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e CVE-2024-53214 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: Release resources at card release The current 6fire code tries to release the resources right after the call of usb6fire_chip_abort(). But at this moment, the card object might be still in use (as we're calling snd_card_free_when_closed()). For avoid potential UAFs, move the release of resources to the card's private_free instead of the manual call of usb6fire_chip_destroy() at the USB disconnect callback. CVE-2024-53239 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: xen/netfront: fix crash when removing device When removing a netfront device directly after a suspend/resume cycle it might happen that the queues have not been setup again, causing a crash during the attempt to stop the queues another time. Fix that by checking the queues are existing before trying to stop them. This is XSA-465 / CVE-2024-53240. CVE-2024-53240 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 moderate In the Linux kernel, the following vulnerability has been resolved: x86/xen: don't do PV iret hypercall through hypercall page Instead of jumping to the Xen hypercall page for doing the iret hypercall, directly code the required sequence in xen-asm.S. This is done in preparation of no longer using hypercall page at all, as it has shown to cause problems with speculation mitigations. This is part of XSA-466 / CVE-2024-53241. CVE-2024-53241 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan() Replace one-element array with a flexible-array member in `struct mwifiex_ie_types_wildcard_ssid_params` to fix the following warning on a MT8173 Chromebook (mt8173-elm-hana): [ 356.775250] ------------[ cut here ]------------ [ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1) [ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex] The "(size 6)" above is exactly the length of the SSID of the network this device was connected to. The source of the warning looks like: ssid_len = user_scan_in->ssid_list[i].ssid_len; [...] memcpy(wildcard_ssid_tlv->ssid, user_scan_in->ssid_list[i].ssid, ssid_len); There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this struct, but it already didn't account for the size of the one-element array, so it doesn't need to be changed. CVE-2024-56539 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: hfsplus: don't query the device logical block size multiple times Devices block sizes may change. One of these cases is a loop device by using ioctl LOOP_SET_BLOCK_SIZE. While this may cause other issues like IO being rejected, in the case of hfsplus, it will allocate a block by using that size and potentially write out-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the latter function reads a different io_size. Using a new min_io_size initally set to sb_min_blocksize works for the purposes of the original fix, since it will be set to the max between HFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use the max between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is not initialized. Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024 and 4096. The produced KASAN report before the fix looks like this: [ 419.944641] ================================================================== [ 419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a [ 419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678 [ 419.947612] [ 419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84 [ 419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 419.950035] Call Trace: [ 419.950384] <TASK> [ 419.950676] dump_stack_lvl+0x57/0x78 [ 419.951212] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.951830] print_report+0x14c/0x49e [ 419.952361] ? __virt_addr_valid+0x267/0x278 [ 419.952979] ? kmem_cache_debug_flags+0xc/0x1d [ 419.953561] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.954231] kasan_report+0x89/0xb0 [ 419.954748] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.955367] hfsplus_read_wrapper+0x659/0xa0a [ 419.955948] ? __pfx_hfsplus_read_wrapper+0x10/0x10 [ 419.956618] ? do_raw_spin_unlock+0x59/0x1a9 [ 419.957214] ? _raw_spin_unlock+0x1a/0x2e [ 419.957772] hfsplus_fill_super+0x348/0x1590 [ 419.958355] ? hlock_class+0x4c/0x109 [ 419.958867] ? __pfx_hfsplus_fill_super+0x10/0x10 [ 419.959499] ? __pfx_string+0x10/0x10 [ 419.960006] ? lock_acquire+0x3e2/0x454 [ 419.960532] ? bdev_name.constprop.0+0xce/0x243 [ 419.961129] ? __pfx_bdev_name.constprop.0+0x10/0x10 [ 419.961799] ? pointer+0x3f0/0x62f [ 419.962277] ? __pfx_pointer+0x10/0x10 [ 419.962761] ? vsnprintf+0x6c4/0xfba [ 419.963178] ? __pfx_vsnprintf+0x10/0x10 [ 419.963621] ? setup_bdev_super+0x376/0x3b3 [ 419.964029] ? snprintf+0x9d/0xd2 [ 419.964344] ? __pfx_snprintf+0x10/0x10 [ 419.964675] ? lock_acquired+0x45c/0x5e9 [ 419.965016] ? set_blocksize+0x139/0x1c1 [ 419.965381] ? sb_set_blocksize+0x6d/0xae [ 419.965742] ? __pfx_hfsplus_fill_super+0x10/0x10 [ 419.966179] mount_bdev+0x12f/0x1bf [ 419.966512] ? __pfx_mount_bdev+0x10/0x10 [ 419.966886] ? vfs_parse_fs_string+0xce/0x111 [ 419.967293] ? __pfx_vfs_parse_fs_string+0x10/0x10 [ 419.967702] ? __pfx_hfsplus_mount+0x10/0x10 [ 419.968073] legacy_get_tree+0x104/0x178 [ 419.968414] vfs_get_tree+0x86/0x296 [ 419.968751] path_mount+0xba3/0xd0b [ 419.969157] ? __pfx_path_mount+0x10/0x10 [ 419.969594] ? kmem_cache_free+0x1e2/0x260 [ 419.970311] do_mount+0x99/0xe0 [ 419.970630] ? __pfx_do_mount+0x10/0x10 [ 419.971008] __do_sys_mount+0x199/0x1c9 [ 419.971397] do_syscall_64+0xd0/0x135 [ 419.971761] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 419.972233] RIP: 0033:0x7c3cb812972e [ 419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48 [ 419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5 [ 419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e [ 419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI: ---truncated--- CVE-2024-56548 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: ovl: Filter invalid inodes with missing lookup function Add a check to the ovl_dentry_weird() function to prevent the processing of directory inodes that lack the lookup function. This is important because such inodes can cause errors in overlayfs when passed to the lowerstack. CVE-2024-56570 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 moderate In the Linux kernel, the following vulnerability has been resolved: jfs: array-index-out-of-bounds fix in dtReadFirst The value of stbl can be sometimes out of bounds due to a bad filesystem. Added a check with appopriate return of error code in that case. CVE-2024-56598 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: net: inet6: do not leave a dangling sk pointer in inet6_create() sock_init_data() attaches the allocated sk pointer to the provided sock object. If inet6_create() fails later, the sk object is released, but the sock object retains the dangling sk pointer, which may cause use-after-free later. Clear the sock sk pointer on error. CVE-2024-56600 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: net: inet: do not leave a dangling sk pointer in inet_create() sock_init_data() attaches the allocated sk object to the provided sock object. If inet_create() fails later, the sk object is freed, but the sock object retains the dangling pointer, which may create use-after-free later. Clear the sk pointer in the sock object on error. CVE-2024-56601 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: net: ieee802154: do not leave a dangling sk pointer in ieee802154_create() sock_init_data() attaches the allocated sk object to the provided sock object. If ieee802154_create() fails later, the allocated sk object is freed, but the dangling pointer remains in the provided sock object, which may allow use-after-free. Clear the sk pointer in the sock object on error. CVE-2024-56602 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc() bt_sock_alloc() attaches allocated sk object to the provided sock object. If rfcomm_dlc_alloc() fails, we release the sk object, but leave the dangling pointer in the sock object, which may cause use-after-free. Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc(). CVE-2024-56604 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create() bt_sock_alloc() allocates the sk object and attaches it to the provided sock object. On error l2cap_sock_alloc() frees the sk object, but the dangling pointer is still attached to the sock object, which may create use-after-free in other code. CVE-2024-56605 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry() Syzbot reported that when searching for records in a directory where the inode's i_size is corrupted and has a large value, memory access outside the folio/page range may occur, or a use-after-free bug may be detected if KASAN is enabled. This is because nilfs_last_byte(), which is called by nilfs_find_entry() and others to calculate the number of valid bytes of directory data in a page from i_size and the page index, loses the upper 32 bits of the 64-bit size information due to an inappropriate type of local variable to which the i_size value is assigned. This caused a large byte offset value due to underflow in the end address calculation in the calling nilfs_find_entry(), resulting in memory access that exceeds the folio/page size. Fix this issue by changing the type of the local variable causing the bit loss from "unsigned int" to "u64". The return value of nilfs_last_byte() is also of type "unsigned int", but it is truncated so as not to exceed PAGE_SIZE and no bit loss occurs, so no change is required. CVE-2024-56619 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix use after free on unload System crash is observed with stack trace warning of use after free. There are 2 signals to tell dpc_thread to terminate (UNLOADING flag and kthread_stop). On setting the UNLOADING flag when dpc_thread happens to run at the time and sees the flag, this causes dpc_thread to exit and clean up itself. When kthread_stop is called for final cleanup, this causes use after free. Remove UNLOADING signal to terminate dpc_thread. Use the kthread_stop as the main signal to exit dpc_thread. [596663.812935] kernel BUG at mm/slub.c:294! [596663.812950] invalid opcode: 0000 [#1] SMP PTI [596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1 [596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012 [596663.812974] RIP: 0010:__slab_free+0x17d/0x360 ... [596663.813008] Call Trace: [596663.813022] ? __dentry_kill+0x121/0x170 [596663.813030] ? _cond_resched+0x15/0x30 [596663.813034] ? _cond_resched+0x15/0x30 [596663.813039] ? wait_for_completion+0x35/0x190 [596663.813048] ? try_to_wake_up+0x63/0x540 [596663.813055] free_task+0x5a/0x60 [596663.813061] kthread_stop+0xf3/0x100 [596663.813103] qla2x00_remove_one+0x284/0x440 [qla2xxx] CVE-2024-56623 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Fix slab-use-after-free read in sg_release() Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN: BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5838 __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407 In sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) is called before releasing the open_rel_lock mutex. The kref_put() call may decrement the reference count of sfp to zero, triggering its cleanup through sg_remove_sfp(). This cleanup includes scheduling deferred work via sg_remove_sfp_usercontext(), which ultimately frees sfp. After kref_put(), sg_release() continues to unlock open_rel_lock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error. Move the kref_put(&sfp->f_ref, sg_remove_sfp) call after unlocking the open_rel_lock mutex. This ensures: - No references to sfp or sdp occur after the reference count is decremented. - Cleanup functions such as sg_remove_sfp() and sg_remove_sfp_usercontext() can safely execute without impacting the mutex handling in sg_release(). The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sg_release(). CVE-2024-56631 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: tipc: Fix use-after-free of kernel socket in cleanup_bearer(). syzkaller reported a use-after-free of UDP kernel socket in cleanup_bearer() without repro. [0][1] When bearer_disable() calls tipc_udp_disable(), cleanup of the UDP kernel socket is deferred by work calling cleanup_bearer(). tipc_exit_net() waits for such works to finish by checking tipc_net(net)->wq_count. However, the work decrements the count too early before releasing the kernel socket, unblocking cleanup_net() and resulting in use-after-free. Let's move the decrement after releasing the socket in cleanup_bearer(). [0]: ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830 [1]: BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline] BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [inline] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [inline] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244 Uninit was created at: slab_free_hook mm/slub.c:2269 [inline] slab_free mm/slub.c:4580 [inline] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [inline] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244 CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: events cleanup_bearer CVE-2024-56642 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: can: j1939: j1939_session_new(): fix skb reference counting Since j1939_session_skb_queue() does an extra skb_get() for each new skb, do the same for the initial one in j1939_session_new() to avoid refcount underflow. [mkl: clean up commit message] CVE-2024-56645 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: net: hsr: avoid potential out-of-bound access in fill_frame_info() syzbot is able to feed a packet with 14 bytes, pretending it is a vlan one. Since fill_frame_info() is relying on skb->mac_len already, extend the check to cover this case. BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline] BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 fill_frame_info net/hsr/hsr_forward.c:709 [inline] hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606 __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434 dev_queue_xmit include/linux/netdevice.h:3168 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [inline] alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881 packet_alloc_skb net/packet/af_packet.c:2995 [inline] packet_snd net/packet/af_packet.c:3089 [inline] packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CVE-2024-56648 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: fix LED ID check in led_tg_check() Syzbot has reported the following BUG detected by KASAN: BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70 Read of size 1 at addr ffff8881022da0c8 by task repro/5879 ... Call Trace: <TASK> dump_stack_lvl+0x241/0x360 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? _printk+0xd5/0x120 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 print_report+0x169/0x550 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x45f/0x530 ? __phys_addr+0xba/0x170 ? strlen+0x58/0x70 kasan_report+0x143/0x180 ? strlen+0x58/0x70 strlen+0x58/0x70 kstrdup+0x20/0x80 led_tg_check+0x18b/0x3c0 xt_check_target+0x3bb/0xa40 ? __pfx_xt_check_target+0x10/0x10 ? stack_depot_save_flags+0x6e4/0x830 ? nft_target_init+0x174/0xc30 nft_target_init+0x82d/0xc30 ? __pfx_nft_target_init+0x10/0x10 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? rcu_is_watching+0x15/0xb0 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? __kmalloc_noprof+0x21a/0x400 nf_tables_newrule+0x1860/0x2980 ? __pfx_nf_tables_newrule+0x10/0x10 ? __nla_parse+0x40/0x60 nfnetlink_rcv+0x14e5/0x2ab0 ? __pfx_validate_chain+0x10/0x10 ? __pfx_nfnetlink_rcv+0x10/0x10 ? __lock_acquire+0x1384/0x2050 ? netlink_deliver_tap+0x2e/0x1b0 ? __pfx_lock_release+0x10/0x10 ? netlink_deliver_tap+0x2e/0x1b0 netlink_unicast+0x7f8/0x990 ? __pfx_netlink_unicast+0x10/0x10 ? __virt_addr_valid+0x183/0x530 ? __check_object_size+0x48e/0x900 netlink_sendmsg+0x8e4/0xcb0 ? __pfx_netlink_sendmsg+0x10/0x10 ? aa_sock_msg_perm+0x91/0x160 ? __pfx_netlink_sendmsg+0x10/0x10 __sock_sendmsg+0x223/0x270 ____sys_sendmsg+0x52a/0x7e0 ? __pfx_____sys_sendmsg+0x10/0x10 __sys_sendmsg+0x292/0x380 ? __pfx___sys_sendmsg+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? exc_page_fault+0x590/0x8c0 ? do_syscall_64+0xb6/0x230 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... </TASK> Since an invalid (without '\0' byte at all) byte sequence may be passed from userspace, add an extra check to ensure that such a sequence is rejected as possible ID and so never passed to 'kstrdup()' and further. CVE-2024-56650 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: net: defer final 'struct net' free in netns dismantle Ilya reported a slab-use-after-free in dst_destroy [1] Issue is in xfrm6_net_init() and xfrm4_net_init() : They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops. But net structure might be freed before all the dst callbacks are called. So when dst_destroy() calls later : if (dst->ops->destroy) dst->ops->destroy(dst); dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed. See a relevant issue fixed in : ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") A fix is to queue the 'struct net' to be freed after one another cleanup_net() round (and existing rcu_barrier()) [1] BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112) Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0 Dec 03 05:46:18 kernel: CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67 Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:124) print_address_description.constprop.0 (mm/kasan/report.c:378) ? dst_destroy (net/core/dst.c:112) print_report (mm/kasan/report.c:489) ? dst_destroy (net/core/dst.c:112) ? kasan_addr_to_slab (mm/kasan/common.c:37) kasan_report (mm/kasan/report.c:603) ? dst_destroy (net/core/dst.c:112) ? rcu_do_batch (kernel/rcu/tree.c:2567) dst_destroy (net/core/dst.c:112) rcu_do_batch (kernel/rcu/tree.c:2567) ? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406) rcu_core (kernel/rcu/tree.c:2825) handle_softirqs (kernel/softirq.c:554) __irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637) irq_exit_rcu (kernel/softirq.c:651) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049) </IRQ> <TASK> asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702) RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743) Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246 RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000 R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000 ? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148) ? cpuidle_idle_call (kernel/sched/idle.c:186) default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118) cpuidle_idle_call (kernel/sched/idle.c:186) ? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168) ? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406) ? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59) do_idle (kernel/sched/idle.c:326) cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1)) start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282) ? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232) ? soft_restart_cpu (arch/x86/kernel/head_64.S:452) common_startup_64 (arch/x86/kernel/head_64.S:414) </TASK> Dec 03 05:46:18 kernel: Allocated by task 12184: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141) copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480) create_new_namespaces ---truncated--- CVE-2024-56658 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: tipc: fix NULL deref in cleanup_bearer() syzbot found [1] that after blamed commit, ub->ubsock->sk was NULL when attempting the atomic_dec() : atomic_dec(&tipc_net(sock_net(ub->ubsock->sk))->wq_count); Fix this by caching the tipc_net pointer. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] CPU: 0 UID: 0 PID: 5896 Comm: kworker/0:3 Not tainted 6.13.0-rc1-next-20241203-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: events cleanup_bearer RIP: 0010:read_pnet include/net/net_namespace.h:387 [inline] RIP: 0010:sock_net include/net/sock.h:655 [inline] RIP: 0010:cleanup_bearer+0x1f7/0x280 net/tipc/udp_media.c:820 Code: 18 48 89 d8 48 c1 e8 03 42 80 3c 28 00 74 08 48 89 df e8 3c f7 99 f6 48 8b 1b 48 83 c3 30 e8 f0 e4 60 00 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00 74 08 48 89 df e8 1a f7 99 f6 49 83 c7 e8 48 8b 1b RSP: 0018:ffffc9000410fb70 EFLAGS: 00010206 RAX: 0000000000000006 RBX: 0000000000000030 RCX: ffff88802fe45a00 RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffc9000410f900 RBP: ffff88807e1f0908 R08: ffffc9000410f907 R09: 1ffff92000821f20 R10: dffffc0000000000 R11: fffff52000821f21 R12: ffff888031d19980 R13: dffffc0000000000 R14: dffffc0000000000 R15: ffff88807e1f0918 FS: 0000000000000000(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556ca050b000 CR3: 0000000031c0c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 CVE-2024-56661 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix race between element replace and close() Element replace (with a socket different from the one stored) may race with socket's close() link popping & unlinking. __sock_map_delete() unconditionally unrefs the (wrong) element: // set map[0] = s0 map_update_elem(map, 0, s0) // drop fd of s0 close(s0) sock_map_close() lock_sock(sk) (s0!) sock_map_remove_links(sk) link = sk_psock_link_pop() sock_map_unlink(sk, link) sock_map_delete_from_link // replace map[0] with s1 map_update_elem(map, 0, s1) sock_map_update_elem (s1!) lock_sock(sk) sock_map_update_common psock = sk_psock(sk) spin_lock(&stab->lock) osk = stab->sks[idx] sock_map_add_link(..., &stab->sks[idx]) sock_map_unref(osk, &stab->sks[idx]) psock = sk_psock(osk) sk_psock_put(sk, psock) if (refcount_dec_and_test(&psock)) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) unlock_sock(sk) __sock_map_delete spin_lock(&stab->lock) sk = *psk // s1 replaced s0; sk == s1 if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch sk = xchg(psk, NULL) if (sk) sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle psock = sk_psock(sk) sk_psock_put(sk, psock) if (refcount_dec_and_test()) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) release_sock(sk) Then close(map) enqueues bpf_map_free_deferred, which finally calls sock_map_free(). This results in some refcount_t warnings along with a KASAN splat [1]. Fix __sock_map_delete(), do not allow sock_map_unref() on elements that may have been replaced. [1]: BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330 Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063 CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Workqueue: events_unbound bpf_map_free_deferred Call Trace: <TASK> dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 kasan_check_range+0x10f/0x1e0 sock_map_free+0x10e/0x330 bpf_map_free_deferred+0x173/0x320 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 1202: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 unix_create1+0x88/0x8a0 unix_create+0xc5/0x180 __sock_create+0x241/0x650 __sys_socketpair+0x1ce/0x420 __x64_sys_socketpair+0x92/0x100 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 46: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 sk_psock_destroy+0x73e/0xa50 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 The bu ---truncated--- CVE-2024-56664 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: 9p/xen: fix release of IRQ Kernel logs indicate an IRQ was double-freed. Pass correct device ID during IRQ release. [Dominique: remove confusing variable reset to 0] CVE-2024-56704 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 moderate GNU GRUB (aka GRUB2) through 2.12 has a heap-based buffer overflow in fs/hfs.c via crafted sblock data in an HFS filesystem. CVE-2024-56737 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 important In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free when COWing tree bock and tracing is enabled When a COWing a tree block, at btrfs_cow_block(), and we have the tracepoint trace_btrfs_cow_block() enabled and preemption is also enabled (CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extent buffer while inside the tracepoint code. This is because in some paths that call btrfs_cow_block(), such as btrfs_search_slot(), we are holding the last reference on the extent buffer @buf so btrfs_force_cow_block() drops the last reference on the @buf extent buffer when it calls free_extent_buffer_stale(buf), which schedules the release of the extent buffer with RCU. This means that if we are on a kernel with preemption, the current task may be preempted before calling trace_btrfs_cow_block() and the extent buffer already released by the time trace_btrfs_cow_block() is called, resulting in a use-after-free. Fix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() to btrfs_force_cow_block() before the COWed extent buffer is freed. This also has a side effect of invoking the tracepoint in the tree defrag code, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() is called there, but this is fine and it was actually missing there. CVE-2024-56759 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: net/smc: check return value of sock_recvmsg when draining clc data When receiving clc msg, the field length in smc_clc_msg_hdr indicates the length of msg should be received from network and the value should not be fully trusted as it is from the network. Once the value of length exceeds the value of buflen in function smc_clc_wait_msg it may run into deadloop when trying to drain the remaining data exceeding buflen. This patch checks the return value of sock_recvmsg when draining data in case of deadloop in draining. CVE-2024-57791 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: power: supply: gpio-charger: Fix set charge current limits Fix set charge current limits for devices which allow to set the lowest charge current limit to be greater zero. If requested charge current limit is below lowest limit, the index equals current_limit_map_size which leads to accessing memory beyond allocated memory. CVE-2024-57792 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req() While receiving an MST up request message from one thread in drm_dp_mst_handle_up_req(), the MST topology could be removed from another thread via drm_dp_mst_topology_mgr_set_mst(false), freeing mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL. This could lead to a NULL deref/use-after-free of mst_primary in drm_dp_mst_handle_up_req(). Avoid the above by holding a reference for mst_primary in drm_dp_mst_handle_up_req() while it's used. v2: Fix kfreeing the request if getting an mst_primary reference fails. CVE-2024-57798 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: s390/cpum_sf: Handle CPU hotplug remove during sampling CPU hotplug remove handling triggers the following function call sequence: CPUHP_AP_PERF_S390_SF_ONLINE --> s390_pmu_sf_offline_cpu() ... CPUHP_AP_PERF_ONLINE --> perf_event_exit_cpu() The s390 CPUMF sampling CPU hotplug handler invokes: s390_pmu_sf_offline_cpu() +--> cpusf_pmu_setup() +--> setup_pmc_cpu() +--> deallocate_buffers() This function de-allocates all sampling data buffers (SDBs) allocated for that CPU at event initialization. It also clears the PMU_F_RESERVED bit. The CPU is gone and can not be sampled. With the event still being active on the removed CPU, the CPU event hotplug support in kernel performance subsystem triggers the following function calls on the removed CPU: perf_event_exit_cpu() +--> perf_event_exit_cpu_context() +--> __perf_event_exit_context() +--> __perf_remove_from_context() +--> event_sched_out() +--> cpumsf_pmu_del() +--> cpumsf_pmu_stop() +--> hw_perf_event_update() to stop and remove the event. During removal of the event, the sampling device driver tries to read out the remaining samples from the sample data buffers (SDBs). But they have already been freed (and may have been re-assigned). This may lead to a use after free situation in which case the samples are most likely invalid. In the best case the memory has not been reassigned and still contains valid data. Remedy this situation and check if the CPU is still in reserved state (bit PMU_F_RESERVED set). In this case the SDBs have not been released an contain valid data. This is always the case when the event is removed (and no CPU hotplug off occured). If the PMU_F_RESERVED bit is not set, the SDB buffers are gone. CVE-2024-57849 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: oss: Fix races at processing SysEx messages OSS sequencer handles the SysEx messages split in 6 bytes packets, and ALSA sequencer OSS layer tries to combine those. It stores the data in the internal buffer and this access is racy as of now, which may lead to the out-of-bounds access. As a temporary band-aid fix, introduce a mutex for serializing the process of the SysEx message packets. CVE-2024-57893 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Correct the migration DMA map direction The SVM DMA device map direction should be set the same as the DMA unmap setting, otherwise the DMA core will report the following warning. Before finialize this solution, there're some discussion on the DMA mapping type(stream-based or coherent) in this KFD migration case, followed by https://lore.kernel.org/all/04d4ab32 -45a1-4b88-86ee-fb0f35a0ca40@amd.com/T/. As there's no dma_sync_single_for_*() in the DMA buffer accessed that because this migration operation should be sync properly and automatically. Give that there's might not be a performance problem in various cache sync policy of DMA sync. Therefore, in order to simplify the DMA direction setting alignment, let's set the DMA map direction as BIDIRECTIONAL. [ 150.834218] WARNING: CPU: 8 PID: 1812 at kernel/dma/debug.c:1028 check_unmap+0x1cc/0x930 [ 150.834225] Modules linked in: amdgpu(OE) amdxcp drm_exec(OE) gpu_sched drm_buddy(OE) drm_ttm_helper(OE) ttm(OE) drm_suballoc_helper(OE) drm_display_helper(OE) drm_kms_helper(OE) i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc sch_fq_codel intel_rapl_msr amd_atl intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd snd_pci_acp6x snd_hda_codec snd_acp_config snd_hda_core snd_hwdep snd_soc_acpi kvm_amd sunrpc snd_pcm kvm binfmt_misc snd_seq_midi crct10dif_pclmul snd_seq_midi_event ghash_clmulni_intel sha512_ssse3 snd_rawmidi nls_iso8859_1 sha256_ssse3 sha1_ssse3 snd_seq aesni_intel snd_seq_device crypto_simd snd_timer cryptd input_leds [ 150.834310] wmi_bmof serio_raw k10temp rapl snd sp5100_tco ipmi_devintf soundcore ccp ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport efi_pstore drm(OE) ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii [ 150.834354] CPU: 8 PID: 1812 Comm: rocrtst64 Tainted: G OE 6.10.0-custom #492 [ 150.834358] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021 [ 150.834360] RIP: 0010:check_unmap+0x1cc/0x930 [ 150.834363] Code: c0 4c 89 4d c8 e8 34 bf 86 00 4c 8b 4d c8 4c 8b 45 c0 48 8b 4d b8 48 89 c6 41 57 4c 89 ea 48 c7 c7 80 49 b4 84 e8 b4 81 f3 ff <0f> 0b 48 c7 c7 04 83 ac 84 e8 76 ba fc ff 41 8b 76 4c 49 8d 7e 50 [ 150.834365] RSP: 0018:ffffaac5023739e0 EFLAGS: 00010086 [ 150.834368] RAX: 0000000000000000 RBX: ffffffff8566a2e0 RCX: 0000000000000027 [ 150.834370] RDX: ffff8f6a8f621688 RSI: 0000000000000001 RDI: ffff8f6a8f621680 [ 150.834372] RBP: ffffaac502373a30 R08: 00000000000000c9 R09: ffffaac502373850 [ 150.834373] R10: ffffaac502373848 R11: ffffffff84f46328 R12: ffffaac502373a40 [ 150.834375] R13: ffff8f6741045330 R14: ffff8f6741a77700 R15: ffffffff84ac831b [ 150.834377] FS: 00007faf0fc94c00(0000) GS:ffff8f6a8f600000(0000) knlGS:0000000000000000 [ 150.834379] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 150.834381] CR2: 00007faf0b600020 CR3: 000000010a52e000 CR4: 0000000000350ef0 [ 150.834383] Call Trace: [ 150.834385] <TASK> [ 150.834387] ? show_regs+0x6d/0x80 [ 150.834393] ? __warn+0x8c/0x140 [ 150.834397] ? check_unmap+0x1cc/0x930 [ 150.834400] ? report_bug+0x193/0x1a0 [ 150.834406] ? handle_bug+0x46/0x80 [ 150.834410] ? exc_invalid_op+0x1d/0x80 [ 150.834413] ? asm_exc_invalid_op+0x1f/0x30 [ 150.834420] ? check_unmap+0x1cc/0x930 [ 150.834425] debug_dma_unmap_page+0x86/0x90 [ 150.834431] ? srso_return_thunk+0x5/0x5f [ 150.834435] ---truncated--- CVE-2024-57897 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 moderate BlueZ HID over GATT Profile Improper Access Control Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of BlueZ. Authentication is not required to exploit this vulnerability. The specific flaw exists within the implementation of the HID over GATT Profile. The issue results from the lack of authorization prior to allowing access to functionality. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-25177. CVE-2024-8805 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:cluster-md-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:dlm-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:gfs2-kmp-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:kernel-default-5.14.21-150400.24.150.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:ocfs2-kmp-default-5.14.21-150400.24.150.1 important When asked to use a `.netrc` file for credentials **and** to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has a `default` entry that omits both login and password. A rare circumstance. CVE-2025-0167 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:curl-8.0.1-150400.5.62.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:libcurl4-8.0.1-150400.5.62.1 moderate When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size. CVE-2025-0395 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:glibc-2.31-150300.92.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:glibc-32bit-2.31-150300.92.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:glibc-i18ndata-2.31-150300.92.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:glibc-locale-2.31-150300.92.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:glibc-locale-base-2.31-150300.92.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:nscd-2.31-150300.92.1 low A flaw was found in command/gpg. In some scenarios, hooks created by loaded modules are not removed when the related module is unloaded. This flaw allows an attacker to force grub2 to call the hooks once the module that registered it was unloaded, leading to a use-after-free vulnerability. If correctly exploited, this vulnerability may result in arbitrary code execution, eventually allowing the attacker to bypass secure boot protections. CVE-2025-0622 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate A flaw was found in grub2. During the network boot process, when trying to search for the configuration file, grub copies data from a user controlled environment variable into an internal buffer using the grub_strcpy() function. During this step, it fails to consider the environment variable length when allocating the internal buffer, resulting in an out-of-bounds write. If correctly exploited, this issue may result in remote code execution through the same network segment grub is searching for the boot information, which can be used to by-pass secure boot protections. CVE-2025-0624 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 important A flaw was found in grub2. When performing a symlink lookup, the grub's UFS module checks the inode's data size to allocate the internal buffer to read the file content, however, it fails to check if the symlink data size has overflown. When this occurs, grub_malloc() may be called with a smaller value than needed. When further reading the data from the disk into the buffer, the grub_ufs_lookup_symlink() function will write past the end of the allocated size. An attack can leverage this by crafting a malicious filesystem, and as a result, it will corrupt data stored in the heap, allowing for arbitrary code execution used to by-pass secure boot mechanisms. CVE-2025-0677 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate A flaw was found in grub2. When reading data from a squash4 filesystem, grub's squash4 fs module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciously crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the direct_read() will perform a heap based out-of-bounds write during data reading. This flaw may be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution, by-passing secure boot protections. CVE-2025-0678 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate A flaw was found in grub2. When performing a symlink lookup from a reiserfs filesystem, grub's reiserfs fs module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_reiserfs_read_symlink() will call grub_reiserfs_read_real() with a overflown length parameter, leading to a heap based out-of-bounds write during data reading. This flaw may be leveraged to corrupt grub's internal critical data and can result in arbitrary code execution, by-passing secure boot protections. CVE-2025-0684 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate A flaw was found in grub2. When reading data from a jfs filesystem, grub's jfs filesystem module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_jfs_lookup_symlink() function will write past the internal buffer length during grub_jfs_read_file(). This issue can be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution, by-passing secure boot protections. CVE-2025-0685 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate A flaw was found in grub2. When performing a symlink lookup from a romfs filesystem, grub's romfs filesystem module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciously crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_romfs_read_symlink() may cause out-of-bounds writes when the calling grub_disk_read() function. This issue may be leveraged to corrupt grub's internal critical data and can result in arbitrary code execution by-passing secure boot protections. CVE-2025-0686 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate When reading data from disk, the grub's UDF filesystem module utilizes the user controlled data length metadata to allocate its internal buffers. In certain scenarios, while iterating through disk sectors, it assumes the read size from the disk is always smaller than the allocated buffer size which is not guaranteed. A crafted filesystem image may lead to a heap-based buffer overflow resulting in critical data to be corrupted, resulting in the risk of arbitrary code execution by-passing secure boot protections. CVE-2025-0689 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate The read command is used to read the keyboard input from the user, while reads it keeps the input length in a 32-bit integer value which is further used to reallocate the line buffer to accept the next character. During this process, with a line big enough it's possible to make this variable to overflow leading to a out-of-bounds write in the heap based buffer. This flaw may be leveraged to corrupt grub's internal critical data and secure boot bypass is not discarded as consequence. CVE-2025-0690 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate When libcurl is asked to perform automatic gzip decompression of content-encoded HTTP responses with the `CURLOPT_ACCEPT_ENCODING` option, **using zlib 1.2.0.3 or older**, an attacker-controlled integer overflow would make libcurl perform a buffer overflow. CVE-2025-0725 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:curl-8.0.1-150400.5.62.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:libcurl4-8.0.1-150400.5.62.1 moderate The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers. CVE-2025-0938 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:python3-3.6.15-150300.10.81.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:python3-curses-3.6.15-150300.10.81.1 moderate A flaw was found in grub2. Grub's dump command is not blocked when grub is in lockdown mode, which allows the user to read any memory information, and an attacker may leverage this in order to extract signatures, salts, and other sensitive information from the memory. CVE-2025-1118 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate When reading data from a hfs filesystem, grub's hfs filesystem module uses user-controlled parameters from the filesystem metadata to calculate the internal buffers size, however it misses to properly check for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculation to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result the hfsplus_open_compressed_real() function will write past of the internal buffer length. This flaw may be leveraged to corrupt grub's internal critical data and may result in arbitrary code execution by-passing secure boot protections. CVE-2025-1125 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-i386-pc-2.06-150400.11.55.2 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:grub2-x86_64-efi-2.06-150400.11.55.2 moderate unknown CVE-2025-24528 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:krb5-1.19.2-150400.3.15.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:krb5-client-1.19.2-150400.3.15.1 moderate A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning the attack complexity high. CVE-2025-26465 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:openssh-8.4p1-150300.3.42.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:openssh-clients-8.4p1-150300.3.42.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:openssh-common-8.4p1-150300.3.42.1 Public Cloud Image google/sles-15-sp4-sap-v20250221-x86-64:openssh-server-8.4p1-150300.3.42.1 moderate