SUSE-IU-2025:2655-1 SUSE Image security@suse.de SUSE Security Team SUSE Image SUSE-IU-2025:2655-1 Interim 1 1 2026-03-19T08:57:27Z current 2025-10-10T01:00:00Z 2025-10-10T01:00:00Z cve-database/bin/generate-cvrf-publiccloud.pl 2021-02-18T01:00:00Z Image update for SUSE-IU-2025:2655-1 / google/sles-12-sp5-v20251010-x86-64 This image update for google/sles-12-sp5-v20251010-x86-64 contains the following changes: Package regionServiceClientConfigGCE was updated: - Update to version 5.0.0 (bsc#1246995) + SLE 16 python-requests requiers SSL v3 certificates. Update 2 region server certs to support SLE 16 when it gets released. - Update conditional to handle name change of metadata package in SLE 16 (bsc#1242063) Package python3-base was updated: - Add CVE-2025-8194-tarfile-no-neg-offsets.patch which now validates archives to ensure member offsets are non-negative (gh#python/cpython#130577, CVE-2025-8194, bsc#1247249). - Add CVE-2025-6069-quad-complex-HTMLParser.patch to avoid worst case quadratic complexity when processing certain crafted malformed inputs with HTMLParser (CVE-2025-6069, bsc#1244705). - Add functools-cached_property.patch adding the port of functools.cached_property from Python 3.8 - Add ipaddress-update-pr60.patch from gh#phihag/ipaddress!60 to update vendored ipaddress module to 3.8 equivalent - Add gh-128840_parse-IPv6-with-emb-IPv4.patch to limit buffer size for IPv6 address parsing (gh#python/cpython#128840, bsc#1244401). - Make the time module statically linked to prevent faliure to start when building. - Update CVE-2024-11168-validation-IPv6-addrs.patch according to the Debian version (gh#python/cpython#103848#issuecomment-2708135083). - Remove python-3.3.0b1-test-posix_fadvise.patch (not needed since kernel 3.6-rc1) Package python was updated: - Add CVE-2025-8194-tarfile-no-neg-offsets.patch which now validates archives to ensure member offsets are non-negative (gh#python/cpython#130577, CVE-2025-8194, bsc#1247249). - Add CVE-2025-6069-quad-complex-HTMLParser.patch to avoid worst case quadratic complexity when processing certain crafted malformed inputs with HTMLParser (CVE-2025-6069, bsc#1244705). Package kernel-default was updated: - usb: xhci: Apply the link chain quirk on NEC isoc endpoints (CVE-2025-22022 bsc#1241292). - commit b35c518 - usb: xhci: move link chain bit quirk checks into one helper function (CVE-2025-22022 bsc#1241292). - commit e8f6e8b - drm/framebuffer: Fix object locking in destroy function (bsc#1248130) Fix the locking in drm_gem_fb_destroy(). This is an bug in the backport of commit f6bfc9afc751 (&quot;drm/framebuffer: Acquire internal references on GEM handles&quot;) for bsc#1247255. - commit 8b690c9 - HID: core: Harden s32ton() against conversion to 0 bits (CVE-2025-38556 bsc#1248296) - commit efa9b29 - Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb() (CVE-2025-38473 bsc#1247289) - commit 3bda5d9 - bus: fsl-mc: fix double-free on mc_dev (CVE-2025-38313 bsc#1246342) - commit cfe0da6 - bcache: fix NULL pointer in cache_set_flush() (CVE-2025-38263 bsc#1246248) - commit 0207ad5 - wifi: mac80211: reject TDLS operations when station is not associated (CVE-2025-38644 bsc#1248748). - commit 38baafe - vsock: Do not allow binding to VMADDR_PORT_ANY (bsc#1248511 CVE-2025-38618). - commit 7301855 - USB: gadget: Fix obscure lockdep violation for udc_mutex (CVE-2022-49980 bsc#1245110). - commit e73f583 - usb: gadget: Fix use-after-free bug by not setting udc-&gt;dev.driver (CVE-2022-49980 bsc#1245110). - commit 7b2e080 - usb: gadget: udc: core: Use pr_fmt() to prefix messages (CVE-2022-49980 bsc#1245110). - commit 342cb6b - usb: gadget: core: do not try to disconnect gadget if it is not connected (CVE-2022-49980 bsc#1245110). - commit 6ce9821 - USB: gadget core: Issue -&gt;disconnect() callback from usb_gadget_disconnect() (CVE-2022-49980 bsc#1245110). - commit e372dab - usb: gadget: udc: Use scnprintf() instead of snprintf() (CVE-2022-49980 bsc#1245110). - commit 01ff878 - usb: gadget: udc: remove duplicate &amp; operation (CVE-2022-49980 bsc#1245110). - commit 6258328 - usb: gadget: remove redundant self assignment (CVE-2022-49980 bsc#1245110). - commit aa82e52 - Update patches.suse/perf-core-Exit-early-on-perf_mmap-fail.patch (CVE-2025-38563 bsc#1248306 dependency CVE-2025-38565 bsc#1248377). - commit d0832f2 - thunderbolt: Do not double dequeue a configuration request (CVE-2025-38174 bsc#1245781) - commit 34371af - fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var (CVE-2025-38214 bsc#1246042) - commit 4cdcf0a - tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer (CVE-2025-38184 bsc#1245956) - commit f59dd51 - gve: add missing NULL check for gve_alloc_pending_packet() in TX DQO (CVE-2025-38122 bsc#1245746) - commit c710bdd - net: usb: aqc111: debug info before sanitation (bsc#1245744) - commit 3ab10bb - net: usb: aqc111: fix error handling of usbnet read calls (CVE-2025-38153 bsc#1245744) - commit 0a0b0b6 - VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify (CVE-2025-38102 bsc#1245669) - commit 104e403 - Fix backport of the patch: patches.suse/ext4-fix-race-when-reusing-xattr-blocks.patch (bsc#1247929) - commit 2389678 - USB: gadget: Fix use-after-free Read in usb_udc_uevent() (CVE-2022-49980 bsc#1245110). - commit 5e1438b - perf/core: Prevent VMA split of buffer mappings (CVE-2025-38563 bsc#1248306). - commit 8cbbc54 - perf/core: Exit early on perf_mmap() fail (CVE-2025-38563 bsc#1248306 dependency). - commit 45bf71a - usb: net: sierra: check for no status endpoint (CVE-2025-38474 bsc#1247311). - commit 9d6b398 - perf/core: Don't leak AUX buffer refcount on allocation failure (CVE-2025-38563 bsc#1248306 dependency). - commit 6e78f38 - atm: clip: Fix memory leak of struct clip_vcc (CVE-2025-38546 bsc#1248223). - commit 9623eb0 - hid: hide cleanup of hid_descriptor (CVE-2025-38103 bsc#1245663). - commit 13489bf - HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse() (CVE-2025-38103 bsc#1245663). - commit de56614 - wifi: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev() (CVE-2025-38513 bsc#1248179). - commit 5d08711 - drm/sched: Increment job count before swapping tail spsc queue (CVE-2025-38515 bsc#1248212). - commit c4cd790 - bluetooth put new member for hci_dev at end (CVE-2025-38117 bsc#1245695). - commit 0a0a7e2 - bluetooth: hide change to struct mgmt_pending_cmd (CVE-2025-38117 bsc#1245695). - commit be95d10 - wifi: prevent A-MSDU attacks in mesh networks (CVE-2025-38512 bsc#1248178). - commit b3fbfce - crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY (bsc#1225527) - commit 696796d - clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns (CVE-2025-38499 bsc#1247976) - commit 853d04a - net/packet: fix a race in packet_set_ring() and packet_notifier() (CVE-2025-38617 bsc#1248621). - commit b606d75 - atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister() (CVE-2025-38245 bsc#1246193) - commit b752c31 - atm: Revert atm_account_tx() if copy_from_iter_full() fails (CVE-2025-38190 bsc#1245973) - commit 3bb91d5 - atm: atmtcp: Free invalid length skb in atmtcp_c_send() (CVE-2025-38185 bsc#1246012) - commit eb7640e - crypto: marvell/cesa - Handle zero-length skcipher requests (CVE-2025-38173 bsc#1245769) - commit 202473d - tee: fix compiler warning in tee_shm_register() (CVE-2022-50080 bsc#1244972) - commit 22a7c7b - tee: add overflow check in register_shm_helper() (CVE-2022-50080 bsc#1244972) - commit a02103f - KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0 (CVE-2022-50228 bsc#1244854) - commit ac7e443 - drm/radeon: fix potential buffer overflow in ni_set_mc_special_registers() (CVE-2022-50185 bsc#1244887) - commit 50be8a6 - ALSA: bcd2000: Fix a UAF bug on the error path of probing (CVE-2022-50229 bsc#1244856) - commit f2b2849 - regulator: of: Fix refcount leak bug in of_get_regulation_constraints() (CVE-2022-50191 bsc#1244899) - commit de6ac5a - mmc: sdhci-of-esdhc: Fix refcount leak in esdhc_signal_voltage_switch (CVE-2022-50141 bsc#1244794) - commit 6834f5d - net: atlantic: fix aq_vec index out of range error (CVE-2022-50066 bsc#1244985). - commit 6c25c9e - Update config files. Disable N_GSM (jsc#PED-8240, bsc#1244824, CVE-2022-50116) - commit e07a3f6 - tipc: Fix use-after-free in tipc_conn_close() (CVE-2025-38464 bsc#1247112). - commit 9f4aa7a - xfrm: fix refcount leak in __xfrm_policy_check() (CVE-2022-50007 bsc#1245016) - commit 8245963 - wifi: libertas: Fix possible refcount leak in if_usb_probe() (CVE-2022-50162 bsc#1244773) - commit 67efefc - HID: hidraw: fix a problem of memory leak in hidraw_release() (bsc#1245072) - commit 990e001 - HID: hidraw: fix memory leak in hidraw_release() (CVE-2022-49981 bsc#1245072) - commit ffa8f52 - scsi: target: iscsi: Fix timeout on deleted connection (CVE-2025-38075 bsc#1244734) - commit c2e8d4f - bpf: Fix a data-race around bpf_jit_limit (CVE-2022-49967 bsc#1244964) - commit b2d2477 - crypto: pcrypt - Fix hungtask for PADATA_RESET (CVE-2023-52813 bsc#1225527) - commit b063c0a - RDMA/rxe: Fix error unwind in rxe_create_qp() (CVE-2022-50127 bsc#1244815) - commit bd0b886 - RDMA/qedr: Fix potential memory leak in __qedr_alloc_mr() (CVE-2022-50138 bsc#1244797) - commit 585ba4c - Refresh patches.suse/x86-alternative-Merge-include-files.patch. - commit 61adacf - drm/framebuffer: Acquire internal references on GEM handles (bsc#1247255) - commit 13075c4 - Move pesign-obs-integration requirement from kernel-syms to kernel devel subpackage (bsc#1248108). - commit e707e41 - drm/gem: Acquire references on GEM handles for framebuffers (bsc#1247255 CVE-2025-38449) - commit 4e06401 - KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses (bsc#1242782, CVE-2025-23141). - commit 9f573f0 - netlink: avoid infinite retry looping in netlink_unicast() (CVE-2025-38465 bsc#1247118). - commit 0acd3ff - posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del() (bsc#1246911 CVE-2025-38352). - blacklist.conf: CVE-2022-50159 - commit 0e930ec - kABI fix for net: vlan: fix VLAN 0 refcount imbalance of toggling (CVE-2025-38470 bsc#1247288). - net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime (CVE-2025-38470 bsc#1247288). - net/sched: Abort __tc_modify_qdisc if parent class does not exist (CVE-2025-38457 bsc#1247098). - atm: clip: Fix potential null-ptr-deref in to_atmarpd() (CVE-2025-38460 bsc#1247143). - net: sched: simplify the qdisc_leaf code (CVE-2025-38457 bsc#1247098). - commit bc4b1c9 - x86/its: Align RETs in BHB clear sequence to avoid thunking (bsc#1242006 CVE-2024-28956). - commit 9e72e87 - x86/its: Add &quot;vmexit&quot; option to skip mitigation on some CPUs (bsc#1242006 CVE-2024-28956). - Refresh patches.kabi/cpufeatures-kabi-fix.patch. - commit 7095d7d - x86/its: Enable Indirect Target Selection mitigation (bsc#1242006 CVE-2024-28956). - commit 06978e9 - x86/its: Add support for ITS-safe return thunk (bsc#1242006 CVE-2024-28956). - commit ed80f34 - x86/its: Add support for ITS-safe indirect thunk (bsc#1242006 CVE-2024-28956). - Refresh patches.kabi/cpufeatures-kabi-fix.patch. - commit 847f2c0 - do_change_type(): refuse to operate on unmounted/not ours mounts (CVE-2025-38498 bsc#1247374) - commit fc35a30 - af_packet: Don't send zero-byte data in packet_sendmsg_spkt() (CVE-2022-49975 bsc#1245196). - bpf: Move skb-&gt;len == 0 checks into __bpf_redirect (CVE-2022-49975 bsc#1245196). - bpf: make sure skb-&gt;len != 0 when redirecting to a tunneling device (CVE-2022-49975 bsc#1245196). - net/ieee802154: don't warn zero-sized raw_sendmsg() (CVE-2022-49975 bsc#1245196). - net/af_packet: check len when min_header_len equals to 0 (CVE-2022-49975 bsc#1245196). - bpf: Don't redirect packets with invalid pkt_len (CVE-2022-49975 bsc#1245196). - bpf: in __bpf_redirect_no_mac pull mac only if present (CVE-2022-49975 bsc#1245196). - commit bde4efa - ACPICA: Refuse to evaluate a method if arguments are missing (CVE-2025-38386 bsc#1247138). - commit 2984cfb - x86/asm: Provide ALTERNATIVE_3 (git-fixes). - commit f737462 - nfsd: nfsd4_spo_must_allow() must check this is a v4 compound request (bsc#1247160 CVE-2025-38430). - commit 53125b5 - linkage: Introduce new macros for assembler symbols (git-fixes). - commit e08683f - x86: Simplify retpoline declaration (git-fixes). - Refresh patches.suse/x86-Add-magic-AMD-return-thunk.patch. - Refresh patches.suse/x86-cpu-Fix-up-srso_safe_ret-and-__x86_return_thunk.patch. - Refresh patches.suse/x86-cpu-Rename-srso_-.-_alias-to-srso_alias_-1.patch. - Refresh patches.suse/x86-retpoline-Use-mfunction-return.patch. - Refresh patches.suse/x86-retpoline-kprobes-Fix-position-of-thunk-sections-with-.patch. - Refresh patches.suse/x86-srso-add-a-speculative-ras-overflow-mitigation.patch. - commit 8b2413e - netlink: make sure we allow at least one dump skb (CVE-2025-38465 bsc#1247118). - netlink: Fix rmem check in netlink_broadcast_deliver() (CVE-2025-38465 bsc#1247118). - netlink: Fix wraparounds of sk-&gt;sk_rmem_alloc (CVE-2025-38465 bsc#1247118). - commit 0e7befb - l2tp: convert l2tp_tunnel_list to idr (CVE-2023-53020 bsc#1240224). Fix locking imbalance introduced by earlier backport. (See bsc#1240224 comment 10.) - Refresh patches.suse/l2tp-close-all-race-conditions-in-l2tp_tunnel_regist.patch. - Refresh patches.suse/l2tp-prevent-lockdep-issue-in-l2tp_tunnel_register.patch. - commit e975b9c - l2ip: fix possible use-after-free (CVE-2023-53020 bsc#1240224). A prerequisity for a locking issue fix. - commit c99f095 - x86/alternatives: Add an ALTERNATIVE_3() macro (git-fixes). - commit 7cd3769 - x86/alternatives: Print containing function (git-fixes). - commit 195541d - x86/alternatives: Add macro comments (git-fixes). - commit efb228e - x86/alternative: Merge include files (git-fixes). - Refresh patches.suse/x86-lib-atomic64_386_32-rename-things.patch. - Refresh patches.suse/x86-srso-add-a-speculative-ras-overflow-mitigation.patch. - commit d6a4cdb - fs: prevent out-of-bounds array speculation when closing a file descriptor (CVE-2023-53117 bsc#1242780). - commit f9988ba - update patches.suse/l2tp-close-all-race-conditions-in-l2tp_tunnel_regist.patch Fix locking imbalance in the backport, see bsc#1240224 comment 10. - commit 5e477f0 - net/sched: sch_qfq: Avoid triggering might_sleep in atomic context in qfq_delete_class (CVE-2025-38477 bsc#1247314). - net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtree (CVE-2025-38468 bsc#1247437). - net/sched: sch_qfq: Fix race condition on qfq_aggregate (CVE-2025-38477 bsc#1247314). - commit 7630d26 - x86/its: Enumerate Indirect Target Selection (ITS) bug (bsc#1242006 CVE-2024-28956). - Refresh patches.kabi/cpufeatures-kabi-fix.patch. - commit 42eb2aa - HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove() (git-fixes CVE-2025-21928 bsc#1240722). - commit 1ea59c1 - sched, cpuset: Fix dl_cpu_busy() panic due to empty cs-&gt;cpus_allowed (CVE-2022-50103 bsc#1244840). - commit 42c9f5e - btrfs: harden block_group::bg_list against list_del() races (CVE-2025-37856 bsc#1243068) - commit b816dc5 - crypto: lzo - Fix compression buffer overrun (CVE-2025-38068 bsc#1245210) - commit 7609c8c - KVM: x86: Reset IRTE to host control if *new* route isn't postable (bsc#1242960 CVE-2025-37885). - commit eff0d4a - KVM: x86: Disable posted interrupts for non-standard IRQs delivery modes (bsc#242960 CVE-2025-37885). - commit b7ec59d - kernel-syms.spec: Drop old rpm release number hack (bsc#1247172). - commit b4fa2d1 - virtio-net: ensure the received length does not exceed allocated size (CVE-2025-38375 bsc#1247177). - commit e965903 - vsock/vmci: Clear the vmci transport packet properly when initializing it (CVE-2025-38403 bsc#1247141). - commit 42a6e1c - wifi: carl9170: do not ping device which has failed to load firmware (CVE-2025-38420 bsc#1247279). - commit 77ff409 - crypto: qat - resolve race condition during AER recovery (bsc#1223638 CVE-2024-26974). - crypto: qat - fix double free during reset (bsc#1223638 CVE-2024-26974). - commit 839d708 - Update patches.suse/sch_hfsc-make-hfsc_qlen_notify-idempotent.patch (CVE-2025-37798 bsc#1242414 CVE-2025-38177 bsc#1245986). - commit 9499075 - bdi: Fix up kabi for dev_name addition (bsc#1171844). - bdi: add a -&gt;dev_name field to struct backing_dev_info (bsc#1171844). - commit 2563dd2 - Squashfs: check return result of sb_min_blocksize (bsc#1247147 CVE-2025-38415). - commit 83161f2 - RDMA/core: Always release restrack object (git-fixes) - commit 1647262 - HID: core: ensure the allocated report buffer can contain the reserved report ID (CVE-2025-38495 bsc#1247348). - commit a99e88f - HID: core: do not bypass hid_hw_raw_request (CVE-2025-38494 bsc#1247349). - commit a6f63b8 - net/sched: Always pass notifications when child class becomes empty (CVE-2025-38350 bsc#1246781). - commit a358033 - usb: host: ohci-ppc-of: Fix refcount leak bug (CVE-2022-50033 bsc#1245139). - commit 341200f - crypto: ccp - Use kzalloc for sev ioctl interfaces to prevent kernel memory leak (CVE-2022-50226 bsc#1244860). - commit aa9545e - l2tp: Don't sleep and disable BH under writer-side sk_callback_lock (git-fixes). - Refresh patches.suse/l2tp-close-all-race-conditions-in-l2tp_tunnel_regist.patch. - Refresh patches.suse/l2tp-prevent-lockdep-issue-in-l2tp_tunnel_register.patch. - commit eb080d7 - l2tp: fix a sock refcnt leak in l2tp_tunnel_register (git-fixes). - net: fix a concurrency bug in l2tp_tunnel_register() (bsc#1205711 CVE-2022-4129). - Refresh patches.suse/l2tp-Serialize-access-to-sk_user_data-with-sk_callba.patch. - Refresh patches.suse/l2tp-close-all-race-conditions-in-l2tp_tunnel_regist.patch. - commit 72fa3a1 - loop: Check for overflow while configuring loop (bsc#1245121 CVE-2022-49993). - blacklist.conf: Remove commit from blacklist - commit bb8ea17 - jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata() (bsc#1246253 CVE-2025-38337). - commit 3af075b - ext4: inline: fix len overflow in ext4_prepare_inline_data (bsc#1245976 CVE-2025-38222). - commit 30045aa - __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock (bsc#1245151 CVE-2025-38058). - commit cc3f42a - usb: typec: altmodes/displayport: do not index invalid pin_assignments (CVE-2025-38391 bsc#1247181). - commit de59e61 - scsi: core: Fix unremoved procfs host directory regression (git-fixes). - scsi: core: Fix a procfs host directory removal regression (git-fixes CVE-2023-53118 bsc#1242365). - commit 8e14770 - scsi: core: Fix a source code comment (git-fixes). This isn't super useful per se, but makes applying other patches easier. - commit a0df70c - Bluetooth: MGMT: Protect mgmt_pending list with its own lock (CVE-2025-38117 bsc#1245695). - commit 59a2ea0 - Refresh patches.suse/can-dev-can_put_echo_skb-don-t-crash-kernel-if-can_priv-ec.patch. Fix the following warning: drivers/net/can/dev.c: In function 'can_put_echo_skb': drivers/net/can/dev.c:451:3: warning: 'return' with a value, in function returning void - commit 3c66160 - kabi fix for perf/aux: Fix AUX buffer serialization (bsc#1230581, CVE-2024-46713). - perf/aux: Fix AUX buffer serialization (bsc#1230581, CVE-2024-46713). - commit a370cdb - iommu/arm-smmu: fix possible null-ptr-deref in arm_smmu_device_probe() (CVE-2022-49323 bsc#1238400). - commit 1c0f036 - nvme-tcp: sanitize request list handling (CVE-2025-38264 bsc#1246387). - commit eab9cf4 - iommu/arm-smmu-v3: check return value after calling platform_get_resource() (CVE-2022-49319 bsc#1238374). - commit d41ddd7 - RDMA/core: Update CMA destination address on rdma_resolve_addr (bsc#1210629 CVE-2023-2176) - commit 45a243e - Squashfs: check the inode number is not the invalid value of zero (bsc#1223634 CVE-2024-26982). - commit d6425c9 - RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction (CVE-2025-38211 bsc#1246008) - commit e7cb52a - rpm/kernel-subpackage-spec: Skip brp-strip-debug to avoid file truncation (bsc#1246879) Put the same workaround to avoid file truncation of vmlinux and co in kernel-default-base package, too. - commit 2329734 - Bluetooth: Replace BT_DBG with bt_dev_dbg for management support (CVE-2025-38117 bsc#1245695). - Refresh patches.suse/Bluetooth-MGMT-Fix-not-checking-if-BT_HS-is-enabled.patch. - commit c096742 - Bluetooth: Fix spelling mistakes (CVE-2025-38117 bsc#1245695). - commit 82a31bb - rpm/kernel-binary.spec.in: Ignore return code from ksymtypes compare When using suse-kabi-tools, the RPM build invokes 'ksymvers compare' to compare the resulting symbol CRCs with the reference data. If the values differ, it then invokes 'ksymtypes compare' to provide a detailed report explaining why the symbols differ. The build expects the latter 'ksymtypes compare' command to always return zero, even if the two compared kABI corpuses are different. This is currently the case for 'ksymtypes compare'. However, I plan to update the command to return a non-zero code when the comparison detects any differences. This should ensure consistent behavior with 'ksymvers compare'. Since the build uses 'ksymtypes compare' only for more detailed diagnostics, ignore its return code. - commit 5ac1381 - net: atm: fix /proc/net/atm/lec handling (CVE-2025-38180 bsc#1245970). - net: atm: add lec_mutex (CVE-2025-38323 bsc#1246473). - net: atm: clean up a range check (CVE-2025-38323 bsc#1246473). - commit 273d1a3 - Bluetooth: fix appearance typo in mgmt.c (CVE-2025-38117 bsc#1245695). - commit 7c5fd29 - Bluetooth: mgmt: Use struct_size() helper (CVE-2025-38117 bsc#1245695). - commit 27a3626 - Bluetooth: Use struct_size() helper (CVE-2025-38117 bsc#1245695). - commit a97aa39 - Bluetooth: mgmt: Use struct_size() helper (CVE-2025-38117 bsc#1245695). - commit e452cf2 - Bluetooth: Mark expected switch fall-throughs (CVE-2025-38117 bsc#1245695). - commit 524b16d - Refresh patches.suse/ipv6-mcast-add-RCU-protection-to-mld_newpack.patch. - commit b9c9349 - fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod() (CVE-2025-38312 bsc#1246386). - commit aea2659 - kABI workaround for bluetooth hci_dev changes (CVE-2025-38250 bsc#1246182). - commit 3a445ce - Bluetooth: hci_core: Fix use-after-free in vhci_flush() (CVE-2025-38250 bsc#1246182). - commit 0b02672 - fbcon: Make sure modelist not set on unregistered console (bsc#1245952 CVE-2025-38198) - commit f64b2f2 - serial: mctrl_gpio: split disable_ms into sync and no_sync APIs (CVE-2025-38040 bsc#1245078). - kabi: serial: mctrl_gpio: split disable_ms into sync and no_sync APIs (CVE-2025-38040 bsc#1245078). - commit 3c2fda4 - btrfs: fix deadlock when cloning inline extents and using qgroups (CVE-2021-46987 bsc#1220704) - commit 68d125c - btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref (CVE-2025-38034 bsc#1244792) - commit c1bc05f - btrfs: do not BUG_ON() when freeing tree block after error (CVE-2024-44963 1230216) - commit c7b8e6b - net_sched: red: fix a race in __red_change() (CVE-2025-38108 bsc#1245675). - net: stmmac: make sure that ptp_rate is not 0 before configuring timestamping (CVE-2025-38126 bsc#1245708). - bpf: fix ktls panic with sockmap (CVE-2025-38166 bsc#1245758). - commit 1452ad9 - perf: Fix sample vs do_exit() (bsc#1246547 CVE-2025-38424 bsc#1247293) - commit 887b64f - Update patches.suse/net-clear-the-dst-when-changing-skb-protocol.patch (bsc#1245954 CVE-2025-38192). Fix incorrect CVE reference. - commit 8a5f77c - patches.suse/ext4-fix-warning-in-ext4_iomap_begin-as-race-begin-as-race-between.patch: Remove the patch as it's not needed and is causing deadlocks (bsc#1246459, bsc#1245115, CVE-2022-50082) - commit fab7cb7 - net_sched: sch_sfq: reject invalid perturb period (CVE-2025-38193 bsc#1245945). - commit b90f28d - ipc: fix to protect IPCS lookups using RCU (CVE-2025-38212 bsc#1246029). - commit 3438ce5 - calipso: unlock rcu before returning -EAFNOSUPPORT (CVE-2025-38147 bsc#1245768). - calipso: Don't call calipso functions for AF_INET sk (CVE-2025-38147 bsc#1245768). - commit 6d3ad82 - i40e: fix MMIO write access to an invalid page in i40e_clear_hw (CVE-2025-38200 bsc#1246045). - net: cadence: macb: Fix a possible deadlock in macb_halt_tx (CVE-2025-38094 bsc#1245649). - commit 3fe4112 - drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table (CVE-2025-38319 bsc#1246243). - commit 28370d4 - ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3() (CVE-2025-38249 bsc#1246171). - commit a7d7572 - iopoll: Introduce read_poll_timeout_atomic macro (CVE-2025-38094 bsc#1245649). - net: cadence: Fix a sleep-in-atomic-context bug in macb_halt_tx() (CVE-2025-38094 bsc#1245649). - commit 94f52a4 - net: clear the dst when changing skb protocol (bsc#1245954 CVE-2024-49861). - commit c3ead22 - wifi: ath9k_htc: Abort software beacon handling if disabled (CVE-2025-38157 bsc#1245747). - commit 2580def - RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction (CVE-2025-38161 bsc#1245777) - commit 884e454 - calipso: Fix null-ptr-deref in calipso_req_{set,del}attr() (CVE-2025-38181 bsc#1246000). - net_sched: sch_sfq: fix a potential crash on gso_skb handling (CVE-2025-38115 bsc#1245689). - commit 4ac1c90 - Bluetooth: hci_event: Fix checking conn for le_conn_complete_evt (bsc#1238160 CVE-2022-49138). - commit a00d68a - net: Fix TOCTOU issue in sk_is_readable() (CVE-2025-38112 bsc#1245668). - commit 5d4114f - Bluetooth: hci_event: Fix checking for invalid handle on error status (bsc#1238160 CVE-2022-49138). - commit c843371 - vgacon: Add check for vc_origin address range in vgacon_scroll() (CVE-2025-38213 bsc#1246037). - commit 22c4880 - ALSA: usb-audio: Kill timer properly at removal (CVE-2025-38105 bsc#1245682). - commit 917cf9d - wifi: mac80211: Fix UAF in ieee80211_scan_rx() (CVE-2022-49934 bsc#1245051). - commit cf69513 - rpm/mkspec: Fix missing kernel-syms-rt creation (bsc#1244337) - commit 630f139 - nbd: don't allow reconnect after disconnect (CVE-2025-21731 bsc#1237881). - commit 8a4b419 - vhost-scsi: protect vq-&gt;log_used with vq-&gt;mutex (CVE-2025-38074 bsc#1244735). - commit 18cd652 - Bluetooth: hci_event: Ignore multiple conn complete events (bsc#1238160 CVE-2022-49138). - commit a0784d3 - virtgpu: don't reset on shutdown (git-fixes). - commit b2d9b68 - Refresh patches.suse/kabi-fix-for-prevent-bpf-program-recursion-for-raw-tracepoint-probes.patch. Fix NULL pointer deference leading to a kernel panic/oops (bsc#1245948). - commit 7935351 - crypto: algif_hash - fix double free in hash_accept (CVE-2025-38079 bsc#1245217). - commit 288b933 - virtio: break and reset virtio devices on device_shutdown() (CVE-2025-38064 bsc#1245201). - commit 1ec66e0 - drm/amd/display: clear optc underflow before turn off odm clock (bsc#1245060 CVE-2022-49969) - commit 360b84f - can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds (CVE-2023-52878 bsc#1225000). - commit 71fb63a - smb: client: Fix use-after-free in cifs_fill_dirent (CVE-2025-38051 bsc#1244750). - commit 1258b98 - cxl: Fix a memory leak in an error handling path (CVE-2022-50025 bsc#1245132). - commit fe62ac8 - driver core: fix potential deadlock in __driver_attach (CVE-2022-50149 bsc#1244883). - commit 0cc27e4 - scsi: lpfc: Fix possible memory leak when failing to issue CMF WQE (bsc#1245073 CVE-2022-50027). - commit e689b05 - nvmet-tcp: don't restore null sk_state_change (bsc#1244801 CVE-2025-38035). - commit eece831 - 9p/fd: fix issue of list_del corruption in p9_fd_cancel() (CVE-2022-49768 bsc#1242446). - commit 29f06d8 - blk-mq: Fixup kABI due to added parameter to bio_merge (bsc#1220631 CVE-2021-46984). - commit de58150 - scsi: lpfc: Prevent buffer overflow crashes in debugfs with malformed user input (bsc#1245265 CVE-2022-50030). - commit e1b77ba - kyber: fix out of bounds access when preempted (CVE-2021-46984 bsc#1220631). - blacklist.conf: Remove from blacklist - Refresh patches.kabi/bfq_depth_updated-fix-kABI.patch - commit 8efa3ed - ext4: fix warning in ext4_iomap_begin as race between bmap and write (bsc#1245115 CVE-2022-50082). - commit 06b2a8c - kABI workaround for xsk: Fix race condition in AF_XDP generic RX path (CVE-2025-37920 bsc#1243479). - commit cd1f0aa - xsk: Fix race condition in AF_XDP generic RX path (bsc#1243479 CVE-2025-37920). - commit 0e83480 - vt: Clear selection before changing the font (CVE-2022-49948 bsc#1245058). - commit 3e5249e - 9p: trans_fd/p9_conn_cancel: drop client lock earlier (CVE-2022-49768 bsc#1242446). - commit 4d2a2e9 - net: pktgen: fix access outside of user given buffer in pktgen_thread_write() (CVE-2025-38061 bsc#1245440). - commit fb0f1a2 - net: vlan: don't propagate flags on open (CVE-2025-23163 bsc#1242837). - commit d0e8595 - scsi: storvsc: Increase the timeouts to storvsc_timeout (bsc#1245455). - scsi: storvsc: Don't report the host packet status as the hv status (git-fixes). - commit adbc421 - kernel-obs-qa: Do not depend on srchash when qemu emulation is used In this case the dependency is never fulfilled Fixes: 485ae1da2b88 (&quot;kernel-obs-qa: Use srchash for dependency as well&quot;) - commit a840f87 - firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails (CVE-2022-50087 bsc#1245119). - commit ec5ba42 - Update patches.suse/0001-drm-msm-mdp5-Fix-global-state-lock-backoff.patch (bsc#1238275 CVE-2022-50173 bsc#1244992). - Update patches.suse/0005-video-fbdev-amba-clcd-Fix-refcount-leak-bugs.patch (bsc#1154048 CVE-2022-50109 bsc#1244884). - Update patches.suse/0007-video-fbdev-arkfb-Fix-a-divide-by-zero-bug-in-ark_se.patch (bsc#1154048 CVE-2022-50102 bsc#1244838). - Update patches.suse/0008-dm-thin-fix-use-after-free-crash-in-dm_sm_register_t.patch (git-fixes CVE-2022-50092 bsc#1244848). - Update patches.suse/0008-video-fbdev-vt8623fb-Check-the-size-of-screen-before.patch (bsc#1154048 CVE-2022-50101 bsc#1244839). - Update patches.suse/0009-video-fbdev-arkfb-Check-the-size-of-screen-before-me.patch (bsc#1154048 CVE-2022-50099 bsc#1244842). - Update patches.suse/0010-dm-raid-fix-address-sanitizer-warning-in-raid_status.patch (git-fixes CVE-2022-50084 bsc#1245117). - Update patches.suse/0010-video-fbdev-s3fb-Check-the-size-of-screen-before-mem.patch (bsc#1154048 CVE-2022-50097 bsc#1244845). - Update patches.suse/0011-dm-raid-fix-address-sanitizer-warning-in-raid_resume.patch (git-fixes CVE-2022-50085 bsc#1245147). - Update patches.suse/0011-fbdev-fb_pm2fb-Avoid-potential-divide-by-zero-error.patch (bsc#1154048 CVE-2022-49978 bsc#1245195). - Update patches.suse/0080-drivers-md-fix-a-potential-use-after-free-bug.patch (git-fixes CVE-2022-50022 bsc#1245131). - Update patches.suse/Bluetooth-btsdio-fix-use-after-free-bug-in-btsdio_re.patch (CVE-2023-1989 bsc#1210336 CVE-2023-53145 bsc#1243047 CVE-2023-53063 bsc#1242216). - Update patches.suse/Input-iforce-wake-up-after-clearing-IFORCE_XMIT_RUNN.patch (git-fixes CVE-2022-49954 bsc#1244976). - Update patches.suse/PCI-dwc-Deallocate-EPC-memory-on-dw_pcie_ep_init-err.patch (git-fixes CVE-2022-50146 bsc#1244788). - Update patches.suse/USB-core-Prevent-nested-device-reset-calls.patch (bsc#1206664 CVE-2022-4662 CVE-2022-49936 bsc#1244984). - Update patches.suse/arm64-fix-oops-in-concurrently-setting-insn_emulation-sysctls.patch (git-fixes CVE-2022-50206 bsc#1245152). - Update patches.suse/ath9k-fix-use-after-free-in-ath9k_hif_usb_rx_cb.patch (CVE-2022-1679 bsc#1199487 CVE-2022-50179 bsc#1244886). - Update patches.suse/btrfs-unset-reloc-control-if-transaction-commit-fail.patch (bsc#1212051 CVE-2023-3111 CVE-2022-50067 bsc#1245047). - Update patches.suse/cifs-fix-small-mempool-leak-in-SMB2_negotiate-.patch (bsc#1190317 CVE-2022-49938 bsc#1244820). - Update patches.suse/ext4-add-EXT4_INODE_HAS_XATTR_SPACE-macro-in-xattr.h.patch (bsc#1206878 CVE-2022-50083 bsc#1244968). - Update patches.suse/ext4-avoid-resizing-to-a-partial-cluster-size.patch (bsc#1206880 CVE-2022-50020 bsc#1245129). - Update patches.suse/ftrace-Fix-NULL-pointer-dereference-in-is_ftrace_trampoline-when-ftrace-is-dead.patch (git-fixes CVE-2022-49977 bsc#1244936). - Update patches.suse/iommu-vt-d-avoid-invalid-memory-access-via-node_online-NUMA_NO_N (git-fixes CVE-2022-50093 bsc#1244849). - Update patches.suse/jbd2-fix-assertion-jh-b_frozen_data-NULL-failure-whe.patch (bsc#1202716 CVE-2022-50126 bsc#1244813). - Update patches.suse/kcm-fix-strp_init-order-and-cleanup.patch (git-fixes CVE-2022-49957 bsc#1244966). - Update patches.suse/kprobes-don-t-call-disarm_kprobe-for-disabled-kprobes.patch (git-fixes CVE-2022-50008 bsc#1245009). - Update patches.suse/locking-csd_lock-Change-csdlock_debug-from-early_par.patch (git-fixes CVE-2022-50091 bsc#1244885). - Update patches.suse/md-call-__md_stop_writes-in-md_stop.patch (git-fixes CVE-2022-49987 bsc#1245024). - Update patches.suse/md-raid10-fix-KASAN-warning.patch (git-fixes CVE-2022-50211 bsc#1245140). - Update patches.suse/media-mceusb-Use-new-usb_control_msg_-routines.patch (CVE-2022-3903 bsc#1205220 CVE-2022-49937 bsc#1245057). - Update patches.suse/msft-hv-2639-scsi-storvsc-Remove-WQ_MEM_RECLAIM-from-storvsc_erro.patch (git-fixes CVE-2022-49986 bsc#1244948). - Update patches.suse/net-tap-NULL-pointer-derefence-in-dev_parse_header_p.patch (git-fixes CVE-2022-50073 bsc#1244978). - Update patches.suse/netfilter-nf_tables-do-not-allow-SET_ID-to-refer-to-.patch (bsc#1202095 CVE-2022-2586 CVE-2022-50213 bsc#1244867). - Update patches.suse/pinctrl-devicetree-fix-refcount-leak-in-pinctrl_dt_t.patch (bsc#1242154 CVE-2024-36959 bsc#1225839). - Update patches.suse/powerpc-64-Init-jump-labels-before-parse_early_param.patch (bsc#1065729 CVE-2022-50012 bsc#1245125). - Update patches.suse/powerpc-pci-Fix-get_phb_number-locking.patch (bsc#1065729 CVE-2022-50045 bsc#1244967). - Update patches.suse/powerpc-xive-Fix-refcount-leak-in-xive_get_max_prio.patch (fate#322438 git-fixess CVE-2022-50104 bsc#1244836). - Update patches.suse/s390-fix-double-free-of-GS-and-RI-CBs-on-fork-failure (bsc#1203254 LTC#199911 CVE-2022-49990 bsc#1245006). - Update patches.suse/scsi-qla2xxx-Fix-crash-due-to-stale-SRB-access-aroun.patch (bsc#1201958 CVE-2022-50098 bsc#1244841). - Update patches.suse/scsi-sg-Allow-waiting-for-commands-to-complete-on-removed-device.patch (git-fixes CVE-2022-50215 bsc#1245138). - Update patches.suse/spmi-trace-fix-stack-out-of-bound-access-in-SPMI-tracing-functions.patch (git-fixes CVE-2022-50094 bsc#1244851). - Update patches.suse/staging-rtl8712-fix-use-after-free-bugs.patch (CVE-2022-4095 bsc#1205514 CVE-2022-49956 bsc#1244969). - Update patches.suse/usb-host-Fix-refcount-leak-in-ehci_hcd_ppc_of_probe.patch (git-fixes CVE-2022-50153 bsc#1244786). - Update patches.suse/usb-ohci-nxp-Fix-refcount-leak-in-ohci_hcd_nxp_probe.patch (git-fixes CVE-2022-50152 bsc#1244783). - Update patches.suse/usbnet-Fix-linkwatch-use-after-free-on-disconnect.patch (git-fixes CVE-2022-50220 bsc#1245348). - Update patches.suse/virtio-gpu-fix-a-missing-check-to-avoid-NULL-derefer.patch (git-fixes CVE-2022-50181 bsc#1244901). - Update patches.suse/virtio_net-fix-memory-leak-inside-XPD_TX-with-mergea.patch (git-fixes CVE-2022-50065 bsc#1244986). - commit 4b076ee - selinux: Add boundary check in put_entry() (CVE-2022-50200 bsc#1245149). - commit 90c9727 - RDMA/hfi1: fix potential memory leak in setup_base_ctxt() (CVE-2022-50134 bsc#1244802) - commit 544eb52 - tracing: Fix compilation warning on arm32 (bsc#1243551). - commit f83d64b - tracing: Fix oob write in trace_seq_to_buffer() (CVE-2025-37923 bsc#1243551). - commit ab5c2ad - net_sched: prio: fix a race in prio_tune() (CVE-2025-38083 bsc#1245183). - commit 4ff0382 - tracing: Fix use-after-free in print_graph_function_flags during tracer switching (CVE-2025-22035 bsc#1241544). - commit 93e9f48 - iavf: Fix adminq error handling (CVE-2022-50055 bsc#1245039). - commit cf4815a - ftrace: Return the first found result in lookup_rec() (bsc#1226837). - commit 548c54e - ftrace: Fix possible use-after-free issue in ftrace_location() (CVE-2024-38588 bsc#1226837). - ftrace: Fix possible warning on checking all pages used in ftrace_process_locs() (bsc#1226837). - blacklist.conf: Remove the commit - ftrace: Separate out functionality from ftrace_location_range() (bsc#1226837). - ftrace: Zero out ftrace hashes when a module is removed (bsc#1226837). - commit ca17def - Check for losing the race against dp_altmode_probe (CVE-2024-35790 bsc#1224712). This is a nonstandard fix because the upstream fix includes a cleanup that requires infrastructure that breaks kABI by changing struct device_driver - commit ffe9de9 - bpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser() (CVE-2023-53133 bsc#1242423) - commit 4d2b740 - iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid (CVE-2025-37927 bsc#1243620). - iommu/amd: Fix ivrs_acpihid cmdline parsing code (CVE-2025-37927 bsc#1243620). - commit 3614667 - Remove host-memcpy-hack.h This might have been usefult at some point but we have more things that depend on specific library versions today. - commit 0396c23 - Remove compress-vmlinux.sh /usr/lib/rpm/brp-suse.d/brp-99-compress-vmlinux was added in pesign-obs-integration during SLE12 RC. This workaround can be removed. - commit 19caac0 - Remove try-disable-staging-driver The config for linux-next is autogenerated from master config, and defaults filled for missing options. This is unlikely to enable any staging driver in the first place. - commit a6f21ed - scsi: target: Fix WRITE_SAME No Data Buffer crash (CVE-2022-21546, bsc#1242243). - commit 0b27e73 - kABI fix for net: xfrm: Localize sequence counter per network namespace (CVE-2024-57982 bsc#1237913). - commit e37d325 - xfrm: state: fix out-of-bounds read during lookup (CVE-2024-57982 bsc#1237913). - net: xfrm: Localize sequence counter per network namespace (CVE-2024-57982 bsc#1237913). - commit 03cb718 - RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug (CVE-2025-38024 bsc#1245025) - commit 4f2eb61 - nfs: handle failure of nfs_get_lock_context in unlock path (bsc#1245004 CVE-2025-38023). - commit 1be83c3 - libnvdimm/labels: Fix divide error in nd_label_data_init() (bsc#1244743, CVE-2025-38072). - commit dacc95b - scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus() (CVE-2022-49780 bsc#1242262). - commit 6710526 - Set CPUID_8000_0021_EAX to the right value (20) This is the word in which individual feature flags are defined, so the cpuid_leaf number must match. - Refresh patches.kabi/cpufeatures-kabi-fix.patch. - Refresh patches.suse/x86-bhi-Add-support-for-clearing-branch-history-at-syscall.patch. - Refresh patches.suse/x86-cpufeature-Add-missing-leaf-enumeration.patch. - commit c63ac04 - ALSA: pcm: Fix race of buffer access at PCM OSS layer (CVE-2025-38078 bsc#1244737). - commit 7c6d995 - Move upstreamed sound patch into sorted section - commit 4436fa8 - packaging: Add support for suse-kabi-tools The current workflow to check kABI stability during the RPM build of SUSE kernels consists of the following steps: * The downstream script rpm/modversions unpacks the consolidated kABI symtypes reference data from kabi/&lt;arch&gt;/symtypes-&lt;flavor&gt; and creates individual symref files. * The build performs a regular kernel make. During this operation, genksyms is invoked for each source file. The tool determines type signatures of all exports within the file, reports any differences compared to the associated symref reference, calculates symbol CRCs from the signatures and writes new type data into a symtypes file. * The script rpm/modversions is invoked again, this time it packs all new symtypes files to a consolidated kABI file. * The downstream script rpm/kabi.pl checks symbol CRCs in the new build and compares them to a reference from kabi/&lt;arch&gt;/symvers-&lt;flavor&gt;, taking kabi/severities into account. suse-kabi-tools is a new set of tools to improve the kABI checking process. The suite includes two tools, ksymtypes and ksymvers, which replace the existing scripts rpm/modversions and rpm/kabi.pl, as well as the comparison functionality previously provided by genksyms. The tools have their own source repository and package. The tools provide faster operation and more detailed, unified output. In addition, they allow the use of the new upstream tool gendwarfksyms, which lacks any built-in comparison functionality. The updated workflow is as follows: * The build performs a regular kernel make. During this operation, genksyms (gendwarfksyms) is invoked as usual, determinining signatures and CRCs of all exports and writing the type data to symtypes files. However, genksyms no longer performs any comparison. * 'ksymtypes consolidate' packs all new symtypes files to a consolidated kABI file. * 'ksymvers compare' checks symbol CRCs in the new build and compares them to a reference from kabi/&lt;arch&gt;/symvers-&lt;flavor&gt;, taking kabi/severities into account. The tool writes its result in a human-readable form on standard output and also writes a list of all changed exports (not ignored by kabi/severities) to the changed-exports file. * 'ksymtypes compare' takes the changed-exports file, the consolidated kABI symtypes reference data from kabi/&lt;arch&gt;/symtypes-&lt;flavor&gt; and the new consolidated data. Based on this data, it produces a detailed report explaining why the symbols changed. The patch enables the use of suse-kabi-tools via rpm/config.sh, providing explicit control to each branch. To enable the support, set USE_SUSE_KABI_TOOLS=Yes in the config file. - commit a2c6f89 - netfilter: allow exp not to be removed in nf_ct_find_expectation (CVE-2023-52927 bsc#1239644). - commit c88f971 - kernel-source: Remove log.sh from sources - commit 96bd779 - media: pvrusb2: fix uaf in pvr2_context_set_notify (CVE-2024-26875 bsc#1223118). - commit 9270436 - drm/amdkfd: Fix an illegal memory access (CVE-2023-53090 bsc#1242753). - commit 8280475 - can: bcm: add locking for bcm_op runtime updates (CVE-2025-38004 bsc#1244274). - commit 27f3405 - scsi: drivers: base: Propagate errors through the transport component (bsc#1242548) - commit 19a4dc6 - scsi: drivers: base: Support atomic version of attribute_container_device_trigger (bsc#1242548) - commit 250283f - sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue() (CVE-2025-38000 bsc#1244277). - commit 8634486 - net_sched: Flush gso_skb list too during -&gt;change() (CVE-2025-37992 bsc#1243698). - ipvs: fix uninit-value for saddr in do_output_route4 (CVE-2025-37961 bsc#1243523). - net: tls: explicitly disallow disconnect (CVE-2025-37756 bsc#1242515). - net_sched: Prevent creation of classes with TC_H_ROOT (CVE-2025-21971 bsc#1240799). - vlan: enforce underlying device type (CVE-2025-21920 bsc#1240686). - kcm: close race conditions on sk_receive_queue (CVE-2022-49814 bsc#1242498). - wifi: cfg80211: fix memory leak in query_regdb_file() (CVE-2022-49881 bsc#1242481). - ipvs: fix WARNING in ip_vs_app_net_cleanup() (CVE-2022-49917 bsc#1242406). - commit 225b1ce - net_sched: sch_fifo: implement lockless __fifo_dump() (bsc#1237312) - commit 619fd3b - netfilter: bridge: replace physindev with physinif in nf_bridge_info (CVE-2024-35839 bsc#1224726). - Refresh patches.kabi/kabi-add-__nf_bridge_get_physindev-for-kabi.patch. - commit ec55ccf - kabi: add __nf_bridge_get_physindev() for kabi (bsc#1224726,CVE-2024-35839). - commit 8066fc3 - tipc: fix memory leak in tipc_link_xmit (CVE-2025-37757 bsc#1242521) - commit ca38369 - net: sched: Fix use after free in red_enqueue() (CVE-2022-49921 bsc#1242359) - commit 91e83c2 - netfilter: propagate net to nf_bridge_get_physindev (CVE-2024-35839 bsc#1224726). - Refresh patches.kabi/kabi-add-__nf_queue_get_refs-for-kabi-compliance.patch. - commit 3ffae8c - serial: core: fix transmit-buffer reset and memleak (bsc#1227768 CVE-2021-47527). - commit 1772922 - bnxt_en: Fix out-of-bound memcpy() during ethtool -w (CVE-2025-37911 bsc#1243469). - mlxsw: spectrum_acl_tcam: Fix stack corruption (CVE-2024-26586 bsc#1220243). - net/mlx5: Update error handler for UCTX and UMEM (CVE-2021-47212 bsc#1222709). - commit 5027586 - module: ensure that kobject_put() is safe for module type kobjects (CVE-2025-37995 bsc#1243827) - commit 31568b0 - mkspec: Exclude rt flavor from kernel-syms dependencies (bsc#1244337). - commit 7c95ae0 - Refresh patches.suse/kabi-fix-for-prevent-bpf-program-recursion-for-raw-tracepoint-probes.patch. Fix the kernel Oops (bsc#1244317) - commit 6a26caf - mnt: fix __detach_mounts infinite loop (bsc#1242140). - commit 973877c - MyBS: Do not build kernel-obs-qa with limit_packages Fixes: 58e3f8c34b2b (&quot;bs-upload-kernel: Pass limit_packages also on multibuild&quot;) - commit f4c6047 - MyBS: Simplify qa_expr generation Start with a 0 which makes the expression valid even if there are no QA repositories (currently does not happen). Then separator is always needed. - commit e4c2851 - MyBS: Correctly generate build flags for non-multibuild package limit (bsc# 1244241) Fixes: 0999112774fc (&quot;MyBS: Use buildflags to set which package to build&quot;) - commit 27588c9 - bs-upload-kernel: Pass limit_packages also on multibuild Fixes: 0999112774fc (&quot;MyBS: Use buildflags to set which package to build&quot;) Fixes: 747f601d4156 (&quot;bs-upload-kernel, MyBS, Buildresults: Support multibuild (JSC-SLE#5501, boo#1211226, bsc#1218184)&quot;) - commit 8ef486c - ftrace: Avoid potential division by zero in function_stat_show() (CVE-2025-21898 bsc#1240610). - commit f3b653b - kABI: workaround &quot;bpf: Prevent bpf program recursion for raw tracepoint probes&quot; changes (bsc#1242301 CVE-2022-49764). - commit 06373a9 - nfc: nci: free rx_data_reassembly skb on NCI device cleanup (CVE-2024-26825 bsc#1223065). - commit e2bddb4 - ptp: Fix possible memory leak in ptp_clock_register() (CVE-2021-47455 bsc#1225254). - Refresh patches.kabi/ptp_clock-kABI-workaround.patch. - commit e9de86b - RDMA/srpt: Do not register event handler until srpt device is fully setup (CVE-2024-26872 bsc#1223115) - commit cad3736 - driver core: fix potential NULL pointer dereference in dev_uevent() (CVE-2025-37800 bsc#1242849). - driver core: introduce device_set_driver() helper (CVE-2025-37800 bsc#1242849). - commit f8f225c - Drop rejected CVE fix for driver core Delete patches.suse/driver-core-Fix-uevent_show-vs-driver-detach-race.patch as it was reverted in the upstream (and CVE was rejected). Another form of the fix will follow. - commit c791e65 - kernel-source: Do not use multiple -r in sed parameters This usage is enabled in commit b18d64d (sed: allow multiple (non-conflicting) -E/-r parameters, 2016-07-31) only available since sed 4.3 Fixes: dc2037cd8f94 (&quot;kernel-source: Also replace bin/env&quot; - commit 91ad98e - block: fix resource leak in blk_register_queue() error path (CVE-2025-37980 bsc#1243522) - commit 65b2595 - openvswitch: Fix unsafe attribute parsing in output_userspace() (CVE-2025-37998 bsc#1243836) - commit 1de5c37 - dm-bufio: don't schedule in atomic context (CVE-2025-37928 bsc#1243621) - commit 8d6e517 - mtd: inftlcore: Add error check for inftl_read_oob() (CVE-2025-37892 bsc#1243536) - commit 54793bb - wifi: wl1251: fix memory leak in wl1251_tx_work (CVE-2025-37982 bsc#1243524) - commit 9ed11b8 - netfilter: nf_tables: fix crash when nf_trace is enabled (git-fixes CVE-2022-49622 bsc#1239042). - commit 1ebebaa - netfilter: nf_tables: avoid skb access on nf_stolen (CVE-2022-49622 bsc#1239042). - commit 3d1f851 - netfilter: nf_tables: consolidate rule verdict trace call (bsc#1239042). - commit a2784df - netfilter: nf_tables: remove old nf_log based tracing (bsc#1239042). - Refresh patches.suse/netfilter-nf_tables-check-the-result-of-dereferencin.patch. - Refresh patches.suse/netfilter-nf_tables-use-WARN_ON_ONCE-instead-of-BUG_.patch. - commit c5a2d73 - KVM: SVM: fix panic on out-of-bounds guest IRQ (bsc#1238167 CVE-2022-49154). - commit 930b864 - Update tags in patches.suse/ocfs2-fix-data-corruption-after-failed-write.patch (bsc#1208542 CVE-2023-53081 bsc#1242281). - commit 54cff45 - ext4: update s_journal_inum if it changes after journal replay (bsc#1242767 CVE-2023-53091). - commit 36a043e - ext4: fix BUG_ON() when directory entry has invalid rec_len (bsc#1242733 CVE-2022-49879). - commit dfbcdb4 - scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command (bsc#1220883 cve-2023-52500 CVE-2023-52500). - commit 8a3dd0b - ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() (bsc#1239071 CVE-2022-49731). - commit f8e7ddf - l2tp: fix lockdep splat (CVE-2023-53020 bsc#1240224). - l2tp: Avoid possible recursive deadlock in l2tp_tunnel_register() (CVE-2023-53020 bsc#1240224). - l2tp: prevent lockdep issue in l2tp_tunnel_register() (CVE-2023-53020 bsc#1240224). - l2tp: close all race conditions in l2tp_tunnel_register() (CVE-2023-53020 bsc#1240224). - blacklist.conf: remove 0b2c59720e65885a394a017d0cf9cab118914682 it is a bit unclear why it was there but it should not be there any more - l2tp: define helper for parsing struct sockaddr_pppol2tp* (CVE-2023-53020 bsc#1240224). - commit 6df99cf - Fix bug reference in patches.suse/net_sched-sch_sfq-use-a-temporary-work-area-for-vali.patch (bsc#1242504) - commit 14f3c70 Package python36 was updated: - Add CVE-2025-8194-tarfile-no-neg-offsets.patch which now validates archives to ensure member offsets are non-negative (gh#python/cpython#130577, CVE-2025-8194, bsc#1247249). - Add CVE-2025-4435-normalize-lnk-trgts-tarfile.patch Security fixes for CVE-2025-4517, CVE-2025-4330, CVE-2025-4138, CVE-2024-12718, CVE-2025-4435 on tarfile (bsc#1244032, bsc#1244061, bsc#1244059, bsc#1244060, bsc#1244056). The backported fixes do not contain changes for ntpath.py and related tests, because the support for symlinks and junctions were added later in Python 3.9, and it does not make sense to backport them to 3.6 here. The patch is contains the following changes: - python@42deeab fixes symlink handling for tarfile.data_filter - python@9d2c2a8 fixes handling of existing files/symlinks in tarfile - python@00af979 adds a new &quot;strict&quot; argument to realpath() - python@dd8f187 fixes mulriple CVE fixes in the tarfile module - downstream only fixes that makes the changes work and compatible with Python 3.6 - Add CVE-2025-6069-quad-complex-HTMLParser.patch to avoid worst case quadratic complexity when processing certain crafted malformed inputs with HTMLParser (CVE-2025-6069, bsc#1244705). - Add python36-* provides/obsoletes to enable SLE-12 -&gt; SLE-15 migration, bsc#1233012 - Add ipaddress-update-pr60.patch from gh#phihag/ipaddress!60 to update vendored ipaddress module to 3.8 equivalent - Add gh-128840_parse-IPv6-with-emb-IPv4.patch to limit buffer size for IPv6 address parsing (gh#python/cpython#128840, bsc#1244401). - Update CVE-2025-4516-DecodeError-handler.patch not to break _PyBytes_DecodeEscape signature. - Add CVE-2025-4516-DecodeError-handler.patch fixing CVE-2025-4516 (bsc#1243273) blocking DecodeError handling vulnerability, which could lead to DoS. Package polkit was updated: - CVE-2025-7519: Fixed that a XML policy file with a large number of nested elements may lead to out-of-bounds write (bsc#1246472) added 0001-Nested-.policy-files-cause-xml-parsing-overflow-lead.patch Package cloud-regionsrv-client was updated: - Update version to 10.5.2 (bsc#1247539) + When an instance fails verification server side the default credentials were left behind requireing manual intervantion prior to the next registration attempt. + Fix issue triggered when using instance-billing-flavor-check due to IP address handling as object rather than string introduced 10.5.0 - Update version to 10.5.1 + Fix issue with picking up configured server names from the regionsrv config file. Previously only IP addresses were collected + Update scriptlet for package uninstall to avoid issues in the build service - Update version to 10.5.0 + Use region server IP addresses to determine Internet access rather than a generic address. Region server IP addresses may not be blocked in the network construct. (bsc#1245305) Package python-base was updated: - Add CVE-2025-8194-tarfile-no-neg-offsets.patch which now validates archives to ensure member offsets are non-negative (gh#python/cpython#130577, CVE-2025-8194, bsc#1247249). - Add CVE-2025-6069-quad-complex-HTMLParser.patch to avoid worst case quadratic complexity when processing certain crafted malformed inputs with HTMLParser (CVE-2025-6069, bsc#1244705). Package gnutls was updated: - Fix 1-byte heap buffer overflow when parsing templates with certtool [bsc#1246267, CVE-2025-32990] * Add patch gnutls-CVE-2025-32990.patch Package cups was updated: - cups-1.7.5-CVE-2025-58364.patch is derived from the upstream patch to fix CVE-2025-58364 &quot;Remote DoS via null dereference&quot; https://github.com/OpenPrinting/cups/security/advisories/GHSA-7qx3-r744-6qv4 bsc#1249128 - cups-1.7.5-CVE-2025-58060.patch is derived from the upstream patch against CUPS 2.4 to fix CVE-2025-58060 &quot;Authentication bypass with AuthType Negotiate&quot; https://github.com/OpenPrinting/cups/security/advisories/GHSA-4c68-qgrh-rmmq bsc#1249049 Package avahi was updated: - Add avahi-CVE-2024-52615.patch: Backport 4e2e1ea from upstream, Resolve fixed source ports for wide-area DNS queries cause DNS responses be injected. (CVE-2024-52615, bsc#1233421) Package net-tools was updated: - Drop old Fedora patch net-tools-1.60-interface_stack.patch. It provided a fix for CVE-2025-46836 (bsc#142461), but it was fixes by the upstream in 2025 in a different way. Revert interferring net-tools-CVE-2025-46836.patch back to the upstream version. - Fix stack buffer overflow in parse_hex (bsc#1248687, GHSA-h667-qrp8-gj58, net-tools-parse_hex-stack-overflow.patch). - Fix stack-based buffer overflow in proc_gen_fmt (bsc#1248687, GHSA-w7jq-cmw2-cq59, net-tools-proc_gen_fmt-buffer-overflow.patch). - Avoid unsafe memcpy in ifconfig (bsc#1248687, net-tools-ifconfig-avoid-unsafe-memcpy.patch). - Prevent overflow in ax25 and netrom (bsc#1248687, net-tools-ax25+netrom-overflow-1.patch, net-tools-ax25+netrom-overflow-2.patch). - Keep possibility to enter long interface names, even if they are not accepted by the kernel, because it was always possible up to CVE-2025-46836 fix. But issue a warning about an interface name concatenation (bsc#1248410, net-tools-ifconfig-long-name-warning.patch). - Provide more readable error for interface name size checking introduced by net-tools-CVE-2025-46836.patch (bsc#1243581, net-tools-CVE-2025-46836-error-reporting.patch). - Fix a regression in net-tools-CVE-2025-46836.patch (bsc#1246608). - Perform bound checks when parsing interface labels in /proc/net/dev (bsc#1243581, CVE-2025-46836, GHSA-pfwf-h6m3-63wf, net-tools-CVE-2025-46836.patch, net-tools-CVE-2025-46836-regression.patch). Package rsync was updated: - Fix bsc#1249363 - rsync client sometimes unable to list modules * Fix order of arguments in rsync-fix-daemon-proto-32.patch * Change spec fie to use %patch -P n -p1 syntax to conform to rpmlint Package pam was updated: - Make sure that the buffer containing encrypted passwords get's erased bedore free. - Replace to previous CVE fix which led to CPU performance issues. [bsc#1246221, CVE-2024-10041, + libpam-introduce-secure-memory-erasure-helpers.patch, + pam_modutil_get-overwrite-password-at-free.patch, - passverify-always-run-the-helper-to-obtain-shadow_pwd.patch, - pam_unix-arbitrary-upper-limit-for-MAX_FD_NO.patch] - pam_unix: Set an arbitrary upper limit for the maximum file descriptor number [pam_unix-arbitrary-upper-limit-for-MAX_FD_NO.patch, bsc#1246221] Package samba was updated: - Windows security hardening locks out schannel'ed netlogon dc calls like netr_DsRGetDCName; (bsc#1246431); (bso#15876). - Update shipped /etc/samba/smb.conf to point to smb.conf man page;(bsc#1233880). Package python-urllib3 was updated: - Add patch CVE-2025-50181-poolmanager-redirects.patch: * Pool managers now properly control redirects when retries is passed (CVE-2025-50181, GHSA-pq67-6m6q-mj2v, bsc#1244925) Package libgcrypt was updated: - Security fix [bsc#1221107, CVE-2024-2236] * Add --enable-marvin-workaround to spec to enable workaround * Fix timing based side-channel in RSA implementation ( Marvin attack ) * Add libgcrypt-CVE-2024-2236_01.patch * Add libgcrypt-CVE-2024-2236_02.patch * Add libgcrypt-CVE-2024-2236_03.patch * Add libgcrypt-CVE-2024-2236_04.patch * Add libgcrypt-CVE-2024-2236_05.patch * Add libgcrypt-CVE-2024-2236_06.patch * Add libgcrypt-CVE-2024-2236_07.patch * Add libgcrypt-CVE-2024-2236_08.patch * Add libgcrypt-CVE-2024-2236_09.patch * Add libgcrypt-CVE-2024-2236_10.patch * Add libgcrypt-CVE-2024-2236_11.patch * Add libgcrypt-CVE-2024-2236_decoding_fix.patch Package coreutils was updated: - coreutils-9.7-sort-CVE-2025-5278.patch: Add upstream patch: sort with key character offsets of SIZE_MAX, could induce a read of 1 byte before an allocated heap buffer. (CVE-2025-5278, bsc#1243767) Package vim was updated: - Fix the following CVEs and bugs: * bsc#1246602 (CVE-2025-53906) * bsc#1246604 (CVE-2025-53905) * bsc#1247939 (CVE-2025-55158) * bsc#1247938 (CVE-2025-55157) - Update to 9.1.1629: 9.1.1629: Vim9: Not able to use more than 10 type arguments in a generic function 9.1.1628: fuzzy.c has a few issues 9.1.1627: fuzzy matching can be improved 9.1.1626: cindent: does not handle compound literals 9.1.1625: Autocompletion slow with include- and tag-completion 9.1.1624: Cscope not enabled on MacOS 9.1.1623: Buffer menu does not handle unicode names correctly 9.1.1622: Patch v9.1.1432 causes performance regressions 9.1.1621: flicker in popup menu during cmdline autocompletion 9.1.1620: filetype: composer.lock and symfony.lock files not recognized 9.1.1619: Incorrect E535 error message 9.1.1618: completion: incorrect selected index returned from complete_info() 9.1.1617: Vim9: some error messages can be improved 9.1.1616: xxd: possible buffer overflow with bitwise output 9.1.1615: diff format erroneously detected 9.1.1614: Vim9: possible variable type change 9.1.1613: tests: test_search leaves a few swapfiles behind 9.1.1612: Ctrl-G/Ctrl-T do not ignore the end search delimiter 9.1.1611: possible undefined behaviour in mb_decompose() 9.1.1610: completion: hang or E684 when 'tagfunc' calls complete() 9.1.1609: complete: Heap-buffer overflow with complete function 9.1.1608: No command-line completion for :unsilent {command} 9.1.1607: :apple command detected as :append 9.1.1606: filetype: a few more files are not recognized 9.1.1605: cannot specify scope for chdir() 9.1.1604: completion: incsearch highlight might be lost 9.1.1603: completion: cannot use autoloaded funcs in 'complete' F{func} 9.1.1602: filetype: requirements-*.txt files are not recognized 9.1.1601: Patch v8.1.0425 was wrong 9.1.1600: using diff anchors with hidden buffers fails silently 9.1.1599: :bnext doesn't go to unlisted help buffers 9.1.1598: filetype: waybar config file is not recognized 9.1.1597: CI reports leaks in libgtk3 library 9.1.1596: tests: Test_search_wildmenu_iminsert() depends on help file 9.1.1595: Wayland: non-portable use of select() 9.1.1594: completion: search completion throws errors 9.1.1593: Confusing error when compiling incomplete try block 9.1.1592: Vim9: crash with classes and garbage collection 9.1.1591: VMS support can be improved 9.1.1590: cannot perform autocompletion 9.1.1589: Cannot disable cscope interface using configure 9.1.1588: Vim9: cannot split dict inside command block 9.1.1587: Wayland: timeout not updated before select() 9.1.1586: Vim9: can define an enum/interface in a function 9.1.1585: Wayland: gvim still needs GVIM_ENABLE_WAYLAND 9.1.1584: using ints as boolean type 9.1.1583: gvim window lost its icons 9.1.1582: style issue in vim9type.c and vim9generics.c 9.1.1581: possible memory leak in vim9generics.c 9.1.1580: possible memory leak in vim9type.c 9.1.1579: Coverity complains about unchecked return value 9.1.1578: configure: comment still mentions autoconf 2.71 9.1.1577: Vim9: no generic support yet 9.1.1576: cannot easily trigger wildcard expansion 9.1.1575: tabpanel not drawn correctly with wrapped lines 9.1.1574: Dead code in mbyte.c 9.1.1573: Memory leak when pressing Ctrl-D in cmdline mode 9.1.1572: expanding $var does not escape whitespace for 'path' 9.1.1571: CmdlineChanged triggered to often 9.1.1570: Copilot suggested some improvements in cmdexpand.c 9.1.1569: tests: Vim9 tests can be improved 9.1.1568: need a few more default highlight groups 9.1.1567: crash when using inline diff mode 9.1.1566: self-referenced enum may not get freed 9.1.1565: configure: does not consider tiny version for wayland 9.1.1564: crash when opening popup to closing buffer 9.1.1563: completion: ruler may disappear 9.1.1562: close button always visible in the 'tabline' 9.1.1561: configure: wayland test can be improved 9.1.1560: configure: uses $PKG_CONFIG before it is defined 9.1.1559: tests: Test_popup_complete_info_01() fails when run alone 9.1.1558: str2blob() treats NULL string and empty string differently 9.1.1557: not possible to anchor specific lines in difff mode 9.1.1556: string handling in cmdexpand.c can be improved 9.1.1555: completion: repeated insertion of leader 9.1.1554: crash when omni-completion opens command-line window 9.1.1553: Vim9: crash when accessing a variable in if condition 9.1.1552: [security]: path traversal issue in tar.vim 9.1.1551: [security]: path traversal issue in zip.vim 9.1.1550: defaults: 'showcmd' is not enabled in non-compatible mode on Unix 9.1.1549: filetype: pkl files are not recognized 9.1.1548: filetype: OpenFGA files are not recognized 9.1.1547: Wayland: missing ifdef 9.1.1546: Vim9: error with has() and short circuit evaluation 9.1.1545: typo in os_unix.c 9.1.1544: :retab cannot be limited to indentation only 9.1.1543: Wayland: clipboard appears to not be working 9.1.1542: Coverity complains about uninitialized variable 9.1.1541: Vim9: error when last enum value ends with a comma 9.1.1540: completion: menu state wrong on interruption 9.1.1539: completion: messages don't respect 'shm' setting 9.1.1537: helptoc: still some issues when markdown code blocks 9.1.1536: tests: test_plugin_comment uses wrong :Check command 9.1.1535: the maximum search count uses hard-coded value 99 9.1.1534: unnecessary code in tabpanel.c 9.1.1533: helptoc: does not handle code sections in markdown well 9.1.1532: termdebug: not enough ways to configure breakpoints 9.1.1531: confusing error with nested legacy function 9.1.1530: Missing version change in v9.1.1529 9.1.1529: Win32: the toolbar in the GUI is old and dated 9.1.1528: completion: crash with getcompletion() 9.1.1527: Vim9: Crash with string compound assignment 9.1.1526: completion: search completion match may differ in case 9.1.1525: tests: testdir/ is a bit messy 9.1.1524: tests: too many imports in the test suite 9.1.1523: tests: test_clipmethod fails in non X11 environment 9.1.1522: tests: still some ANSI escape sequences in test output 9.1.1521: completion: pum does not reset scroll pos on reopen with 'noselect' 9.1.1520: completion: search completion doesn't handle 'smartcase' well 9.1.1519: tests: Test_termdebug_decimal_breakpoints() may fail 9.1.1518: getcompletiontype() may crash 9.1.1517: filetype: autopkgtest files are not recognized 9.1.1516: tests: no test that 'incsearch' is updated after search completion 9.1.1515: Coverity complains about potential unterminated strings 9.1.1514: Coverity complains about the use of tmpfile() 9.1.1513: resizing Vim window causes unexpected internal window width 9.1.1512: completion: can only complete from keyword characters 9.1.1511: tests: two edit tests change v:testing from 1 to 0 9.1.1510: Search completion may use invalid memory 9.1.1509: patch 9.1.1505 was not good 9.1.1508: string manipulation can be improved in cmdexpand.c 9.1.1507: symlinks are resolved on :cd commands 9.1.1506: tests: missing cleanup in Test_search_cmdline_incsearch_highlight() 9.1.1505: not possible to return completion type for :ex command 9.1.1504: filetype: numbat files are not recognized 9.1.1503: filetype: haxe files are not recognized 9.1.1502: filetype: quickbms files are not recognized 9.1.1501: filetype: flix files are not recognized 9.1.1500: if_python: typo in python error variable 9.1.1499: MS-Windows: no indication of ARM64 architecture 9.1.1498: completion: 'complete' funcs behave different to 'omnifunc' 9.1.1497: Link error with shm_open() 9.1.1496: terminal: still not highlighting empty cells correctly 9.1.1495: Wayland: uses $XDG_SEAT to determine seat 9.1.1494: runtime(tutor): no French translation for Chapter 2 9.1.1493: manually comparing positions on buffer 9.1.1492: tests: failure when Wayland compositor fails to start 9.1.1491: missing out-of-memory checks in cmdexpand.c 9.1.1490: 'wildchar' does not work in search contexts 9.1.1489: terminal: no visual highlight of empty cols with empty 'listchars' 9.1.1488: configure: using obsolete macro AC_PROG_GCC_TRADITIONAL 9.1.1487: :cl doesn't invoke :clist 9.1.1486: documentation issues with Wayland 9.1.1485: missing Wayland clipboard support 9.1.1484: tests: Turkish locale tests fails on Mac 9.1.1483: not possible to translation position in buffer 9.1.1482: scrolling with 'splitkeep' and line() 9.1.1481: gcc complains about uninitialized variable 9.1.1480: Turkish translation outdated 9.1.1479: regression when displaying localized percentage position 9.1.1478: Unused assignment in ex_uniq() 9.1.1476: no easy way to deduplicate text 9.1.1476: missing out-of-memory checks in cmdexpand.c 9.1.1475: completion: regression when &quot;nearest&quot; in 'completeopt' 9.1.1474: missing out-of-memory check in mark.c 9.1.1473: inconsistent range arg for :diffget/diffput 9.1.1472: if_python: PySequence_Fast_{GET_SIZE,GET_ITEM} removed 9.1.1471: completion: inconsistent ordering with CTRL-P 9.1.1470: use-after-free with popup callback on error 9.1.1469: potential buffer-underflow with invalid hl_id 9.1.1468: filetype: bright(er)script files are not recognized 9.1.1467: too many strlen() calls 9.1.1466: filetype: not all lex files are recognized 9.1.1465: tabpanel: not correctly drawn with 'equalalways' 9.1.1464: gv does not work in operator-pending mode 9.1.1463: Integer overflow in getmarklist() after linewise operation 9.1.1462: missing change from patch v9.1.1461 9.1.1461: tabpanel: tabpanel vanishes with popup menu 9.1.1460: MS-Windows: too many strlen() calls in os_win32.c 9.1.1459: xxd: coloring output is inefficient 9.1.1458: tabpanel: tabs not properly updated with 'stpl' 9.1.1457: compile warning with tabpanelopt 9.1.1456: comment plugin fails toggling if 'cms' contains \ 9.1.1455: Haiku: dailog objects created with no reference 9.1.1454: tests: no test for pum at line break position 9.1.1453: tests: Test_geometry() may fail 9.1.1452: completion: redundant check for completion flags 9.1.1451: tabpanel rendering artifacts when scrolling 9.1.1450: Session has wrong arglist with :tcd and :arglocal 9.1.1449: typo in pum_display() 9.1.1448: tabpanel is not displayed correctly when msg_scrolled 9.1.1447: completion: crash when backspacing with fuzzy completion 9.1.1446: filetype: cuda-gdb config files are not recognized 9.1.1445: negative matchfuzzy scores although there is a match 9.1.1444: Unused assignment in set_fuzzy_score() 9.1.1443: potential buffer underflow in insertchar() 9.1.1442: tests: Test_diff_fold_redraw() is insufficient 9.1.1441: completion: code can be improved 9.1.1440: too many strlen() calls in os_win32.c 9.1.1439: Last diff folds not merged 9.1.1438: tests: Test_breakindent_list_split() fails 9.1.1437: MS-Windows: internal compile error in uc_list() 9.1.1436: GUI control code is displayed on the console on startup 9.1.1435: completion: various flaws in fuzzy completion 9.1.1434: MS-Windows: missing out-of-memory checks in os_win32.c 9.1.1433: Unnecessary :if when writing session 9.1.1432: GTK GUI: Buffer menu does not handle unicode correctly 9.1.1431: Hit-Enter Prompt when loading session files 9.1.1430: tabpanel may flicker in the GUI 9.1.1429: dragging outside the tabpanel changes tabpagenr 9.1.1428: completion: register completion needs cleanup 9.1.1427: rendering artifacts with the tabpanel 9.1.1426: completion: register contents not completed 9.1.1425: tabpanel: there are still some problems with the tabpanel 9.1.1424: PMenu selection broken with multi-line selection and limits 9.1.1423: :tag command not working correctly using Vim9 Script 9.1.1422: scheduling of complete function can be improved 9.1.1421: tests: need a test for the new-style tutor.tutor 9.1.1420: tests: could need some more tests for shebang lines 9.1.1419: It is difficult to ignore all but some events 9.1.1418: configures GUI auto detection favors GTK2 9.1.1417: missing info about register completion in complete_info() 9.1.1416: completion limits not respected for fuzzy completions 9.1.1415: potential use-after free when there is an error in 'tabpanel' 9.1.1414: MS-Windows: compile warnings in os_win32.c 9.1.1413: spurious CursorHold triggered in GUI on startup 9.1.1412: tests: Test_tabpanel_tabonly() fails on larger screens 9.1.1411: crash when calling non-existing function for tabpanel 9.1.1410: out-of-bounds access with 'completefunc' 9.1.1409: using f-flag in 'complete' conflicts with Neovim 9.1.1408: not easily possible to complete from register content 9.1.1407: Can't use getpos('v') in OptionSet when using setbufvar() Package openssl-1_1 was updated: - Security fix: [bsc#1250232 CVE-2025-9230] * Fix out-of-bounds read &amp; write in RFC 3211 KEK unwrap * Add patch openssl3-CVE-2025-9230.patch Package grub2 was updated: - Fix CVE-2024-56738: side-channel attack due to not constant-time algorithm in grub_crypto_memcmp (bsc#1234959) * grub2-constant-time-grub_crypto_memcmp.patch - Fix page fault due to stricter memory permissions in shim 15.8 with later ovmf built from edk2-stable202502 (bsc#1240771) * 0001-efi-refactor-grub_efi_allocate_pages.patch * 0002-Remove-grub_efi_allocate_pages.patch * 0003-efi-change-heap-allocation-type-to-GRUB_EFI_LOADER_C.patch * 0004-arm64-efi-move-EFI_PAGE-definitions-to-efi-memory.h.patch * 0005-mkimage-Align-efi-sections-on-4k-boundary.patch Package sqlite3 was updated: - Backpatch the URLs in sqlite3.n from https to http to avoid a file conflict with the tcl package on SLE-12. - Sync version 3.50.2 from Factory: * CVE-2025-6965, bsc#1246597: Raise an error early if the number of aggregate terms in a query exceeds the maximum number of columns, to avoid downstream assertion faults. * Add subpackage for the lemon parser generator. + sqlite-3.49.0-fix-lemon-missing-cflags.patch + sqlite-3.6.23-lemon-system-template.patch Package python3 was updated: - Add CVE-2025-8194-tarfile-no-neg-offsets.patch which now validates archives to ensure member offsets are non-negative (gh#python/cpython#130577, CVE-2025-8194, bsc#1247249). Package _product:sle-sdk-release was updated: Package libxml2 was updated: - security update- added patches CVE-2025-7425 [bsc#1246296], Heap Use-After-Free in libxslt caused by atype corruption in xmlAttrPtr + libxml2-CVE-2025-7425.patch - security update - added patches CVE-2025-49794 [bsc#1244554], heap use after free (UAF) can lead to Denial of service (DoS) CVE-2025-49796 [bsc#1244557], type confusion may lead to Denial of service (DoS) + libxml2-CVE-2025-49794,49796.patch - security update - added patches CVE-2025-6170 [bsc#1244700], stack buffer overflow may lead to a crash CVE-2025-6021 [bsc#1244580], Integer Overflow in xmlBuildQName() Leads to Stack Buffer Overflow in libxml2 + libxml2-CVE-2025-6170,6021.patch Package google-guest-oslogin was updated: - Cherry-pick dont-retry-bad-requests.patch to stop retrying bad requests causing timeouts during container startup (bsc#1243992) Package iputils was updated: - Security fix [bsc#1243772, CVE-2025-48964] * Fix integer overflow in ping statistics via zero timestamp * Add iputils-CVE-2025-48964_01.patch * Add iputils-CVE-2025-48964_02.patch Package openssl-1_0_0 was updated: - Security fix: [bsc#1250232 CVE-2025-9230] * Fix out-of-bounds read &amp; write in RFC 3211 KEK unwrap * Add patch openssl3-CVE-2025-9230.patch Package libssh was updated: - Security fix: [CVE-2025-8277, bsc#1249375] * Memory Exhaustion via Repeated Key Exchange * Add patches: - libssh-CVE-2025-8277-packet-Adjust-packet-filter-to-work-wh.patch - libssh-CVE-2025-8277-Fix-memory-leak-of-unused-ephemeral-ke.patch - libssh-CVE-2025-8277-ecdh-Free-previously-allocated-pubkeys.patch - Security fix: [CVE-2025-8114, bsc#1246974] * NULL pointer dereference when calculating session ID during KEX * Add libssh-CVE-2025-8114.patch - Fix CVE-2025-5318: Likely read beyond bounds in sftp server handle management (bsc#1245311) * Add patch libssh-CVE-2025-5318.patch - Fix CVE-2025-4877: Write beyond bounds in binary to base64 conversion functions (bsc#1245309) * Add patch libssh-CVE-2025-4877.patch - Fix CVE-2025-4878: Use of uninitialized variable in privatekey_from_file() (bsc#1245310) * Add patches: - libssh-CVE-2025-4878-1.patch - libssh-CVE-2025-4878-2.patch - Fix CVE-2025-5372: ssh_kdf() returns a success code on certain failures (bsc#1245314) * Add patch libssh-CVE-2025-5372.patch Package curl was updated: - Security fixes: * [bsc#1249191, CVE-2025-9086] Out of bounds read for cookie path * [bsc#1249348, CVE-2025-10148] Predictable WebSocket mask * Add patches: - curl-CVE-2025-9086.patch - curl-CVE-2025-10148.patch Package docker was updated: - Update to docker-buildx v0.28.0. Upstream changelog: &lt;https://github.com/docker/buildx/releases/tag/v0.28.0&gt; - Update to Docker 28.4.0-ce. See upstream changelog online at &lt;https://docs.docker.com/engine/release-notes/28/#2840&gt; - Rebased patches: * 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch * 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch * 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch * 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch * 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch * 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch * cli-0001-openSUSE-point-users-to-docker-buildx-package.patch * cli-0002-SECRETS-SUSE-default-to-DOCKER_BUILDKIT-0-for-docker.patch - Update warnings and errors related to &quot;docker buildx ...&quot; so that they reference our openSUSE docker-buildx packages. + cli-0001-openSUSE-point-users-to-docker-buildx-package.patch - Enable building docker-buildx for SLE15 systems with SUSEConnect secret injection enabled. PED-12534 PED-8905 bsc#1247594 As docker-buildx does not support our SUSEConnect secret injection (and some users depend &quot;docker build&quot; working transparently), patch the docker CLI so that &quot;docker build&quot; will no longer automatically call &quot;docker buildx build&quot;, effectively making DOCKER_BUILDKIT=0 the default configuration. Users can manually use &quot;docker buildx ...&quot; commands or set DOCKER_BUILDKIT=1 in order to opt-in to using docker-buildx. Users can silence the &quot;docker build&quot; warning by setting DOCKER_BUILDKIT=0 explicitly. In order to inject SCC credentials with docker-buildx, users should use RUN --mount=type=secret,id=SCCcredentials zypper -n ... in their Dockerfiles, and docker buildx build --secret id=SCCcredentials,src=/etc/zypp/credentials.d/SCCcredentials,type=file . when doing their builds. + cli-0002-SECRETS-SUSE-default-to-DOCKER_BUILDKIT-0-for-docker.patch - Update to Docker 28.3.3-ce. See upstream changelog online at &lt;https://docs.docker.com/engine/release-notes/28/#2833&gt; CVE-2025-54388 bsc#1247367 - Update to docker-buildx v0.26.1. Upstream changelog: &lt;https://github.com/docker/buildx/releases/tag/v0.26.1&gt; - Update to docker-buildx v0.26.0. Upstream changelog: &lt;https://github.com/docker/buildx/releases/tag/v0.26.0&gt; - Update to Go 1.24 for builds, to match upstream. - Update to Docker 28.3.2-ce. See upstream changelog online at &lt;https://docs.docker.com/engine/release-notes/28/#2832&gt; - Update to Docker 28.3.1-ce. See upstream changelog online at &lt;https://docs.docker.com/engine/release-notes/28/#2831&gt; - Update to Docker 28.3.0-ce. See upstream changelog online at &lt;https://docs.docker.com/engine/release-notes/28/#2830&gt; bsc#1246556 - Rebase patches: * 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch * 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch * 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch * 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch * 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch * 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch [ This update is a no-op, only needed to work around unfortunate automated packaging script behaviour on SLES. ] - The following patches were removed in openSUSE in the Docker 28.1.1-ce update, but the patch names were later renamed in a SLES-only update before Docker 28.1.1-ce was submitted to SLES. This causes the SLES build scripts to refuse the update because the patches are not referenced in the changelog. There is no obvious place to put the patch removals (the 28.1.1-ce update removing the patches chronologically predates their renaming in SLES), so they are included here a dummy changelog entry to work around the issue. - 0007-CVE-2025-22868-vendor-jws-split-token-into-fixed-num.patch - 0008-CVE-2025-22869-vendor-ssh-limit-the-size-of-the-inte.patch - Update to docker-buildx v0.25.0. Upstream changelog: &lt;https://github.com/docker/buildx/releases/tag/v0.25.0&gt; - Do not try to inject SUSEConnect secrets when in Rootless Docker mode, as Docker does not have permission to access the host zypper credentials in this mode (and unprivileged users cannot disable the feature using /etc/docker/suse-secrets-enable.) bsc#1240150 * 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch - Rebase patches: * 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch * 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch * 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch * 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch * 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch - Always clear SUSEConnect suse_* secrets when starting containers regardless of whether the daemon was built with SUSEConnect support. Not doing this causes containers from SUSEConnect-enabled daemons to fail to start when running with SUSEConnect-disabled (i.e. upstream) daemons. This was a long-standing issue with our secrets support but until recently this would've required migrating from SLE packages to openSUSE packages (which wasn't supported). However, as SLE Micro 6.x and SLES 16 will move away from in-built SUSEConnect support, this is now a practical issue users will run into. bsc#1244035 + 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch - Rearrange patches: - 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch + 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch - 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch + 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch - 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch + 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch - 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch + 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch - 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch + 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch [NOTE: This update was only ever released in SLES and Leap.] - Always clear SUSEConnect suse_* secrets when starting containers regardless of whether the daemon was built with SUSEConnect support. Not doing this causes containers from SUSEConnect-enabled daemons to fail to start when running with SUSEConnect-disabled (i.e. upstream) daemons. This was a long-standing issue with our secrets support but until recently this would've required migrating from SLE packages to openSUSE packages (which wasn't supported). However, as SLE Micro 6.x and SLES 16 will move away from in-built SUSEConnect support, this is now a practical issue users will run into. bsc#1244035 + 0001-SECRETS-SUSE-always-clear-our-internal-secrets.patch - Rearrange patches: - 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch + 0002-SECRETS-daemon-allow-directory-creation-in-run-secre.patch - 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch + 0003-SECRETS-SUSE-implement-SUSE-container-secrets.patch - 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch + 0004-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch - 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch + 0005-bsc1073877-apparmor-clobber-docker-default-profile-o.patch - 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch + 0006-SLE12-revert-apparmor-remove-version-conditionals-fr.patch - 0006-CVE-2025-22868-vendor-jws-split-token-into-fixed-num.patch + 0007-CVE-2025-22868-vendor-jws-split-token-into-fixed-num.patch - 0007-CVE-2025-22869-vendor-ssh-limit-the-size-of-the-inte.patch + 0008-CVE-2025-22869-vendor-ssh-limit-the-size-of-the-inte.patch - Update to Docker 28.2.2-ce. See upstream changelog online at &lt;https://docs.docker.com/engine/release-notes/28/#2822&gt; - Rebase patches: * 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch * 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch * 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch * 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch * 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch - Update to Docker 28.2.1-ce. See upstream changelog online at &lt;https://docs.docker.com/engine/release-notes/28/#2820&gt; bsc#1243833 &lt;https://github.com/moby/moby/releases/tag/v28.2.1&gt; - Rebase patches: * 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch * 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch * 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch * 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch * 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch - Update to docker-buildx v0.24.0. Upstream changelog: &lt;https://github.com/docker/buildx/releases/tag/v0.24.0&gt; - Update to Docker 28.1.1-ce. See upstream changelog online at &lt;https://docs.docker.com/engine/release-notes/28/#2811&gt; bsc#1242114 Includes upstream fixes: - CVE-2025-22872 bsc#1241830 - Remove long-outdated build handling for deprecated and unsupported devicemapper and AUFS storage drivers. AUFS was removed in v24, and devicemapper was removed in v25. &lt;https://docs.docker.com/engine/deprecated/#aufs-storage-driver&gt; - Rebase patches: * 0001-SECRETS-daemon-allow-directory-creation-in-run-secre.patch * 0002-SECRETS-SUSE-implement-SUSE-container-secrets.patch * 0003-BUILD-SLE12-revert-graphdriver-btrfs-use-kernel-UAPI.patch * 0004-bsc1073877-apparmor-clobber-docker-default-profile-o.patch * 0005-SLE12-revert-apparmor-remove-version-conditionals-fr.patch - Remove upstreamed patches: - 0006-CVE-2025-22868-vendor-jws-split-token-into-fixed-num.patch - 0007-CVE-2025-22869-vendor-ssh-limit-the-size-of-the-inte.patch - cli-0001-docs-include-required-tools-in-source-tree.patch - Update to docker-buildx v0.23.0. Upstream changelog: &lt;https://github.com/docker/buildx/releases/tag/v0.23.0&gt; 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-12-sp5-v20251010-x86-64/ Public Cloud Image Info https://www.suse.com/support/security/rating/ SUSE Security Ratings Public Cloud Image google/sles-12-sp5-v20251010-x86-64 cloud-regionsrv-client-10.5.2-52.132.1 cloud-regionsrv-client-plugin-gce-1.0.0-52.132.1 coreutils-8.25-13.19.1 cups-libs-1.7.5-20.54.1 curl-8.0.1-11.108.1 docker-28.4.0_ce-98.140.1 google-guest-oslogin-20240311.00-1.40.1 grub2-2.02-190.1 grub2-i386-pc-2.02-190.1 grub2-x86_64-efi-2.02-190.1 iputils-s20161105-11.12.1 kernel-default-4.12.14-122.272.1 libavahi-client3-0.6.32-32.33.1 libavahi-common3-0.6.32-32.33.1 libcurl4-8.0.1-11.108.1 libgcrypt20-1.6.1-16.86.1 libgnutls30-3.4.17-8.20.1 libopenssl1_0_0-1.0.2p-3.98.1 libopenssl1_1-1.1.1d-2.119.1 libpolkit0-0.113-5.30.1 libpython2_7-1_0-2.7.18-33.53.1 libpython3_4m1_0-3.4.10-25.158.1 libpython3_6m1_0-3.6.15-89.1 libsqlite3-0-3.50.2-9.41.1 libssh-config-0.9.8-3.18.1 libssh4-0.9.8-3.18.1 libxml2-2-2.9.4-46.90.1 net-tools-1.60-765.15.1 openssl-1_0_0-1.0.2p-3.98.1 pam-1.1.8-24.77.1 polkit-0.113-5.30.1 python-2.7.18-33.53.1 python-base-2.7.18-33.53.1 python-xml-2.7.18-33.53.1 python3-3.4.10-25.158.1 python3-base-3.4.10-25.158.1 python3-urllib3-1.25.10-3.43.1 python36-base-3.6.15-89.1 regionServiceClientConfigGCE-5.0.0-5.21.1 rsync-3.1.3-3.31.1 samba-client-libs-4.15.13+git.659.be30c436f5a-3.96.1 samba-libs-4.15.13+git.659.be30c436f5a-3.96.1 sqlite3-tcl-3.50.2-9.41.1 vim-9.1.1629-17.51.1 vim-data-common-9.1.1629-17.51.1 cloud-regionsrv-client-10.5.2-52.132.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 cloud-regionsrv-client-plugin-gce-1.0.0-52.132.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 coreutils-8.25-13.19.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 cups-libs-1.7.5-20.54.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 curl-8.0.1-11.108.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 docker-28.4.0_ce-98.140.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 google-guest-oslogin-20240311.00-1.40.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 grub2-2.02-190.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 grub2-i386-pc-2.02-190.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 grub2-x86_64-efi-2.02-190.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 iputils-s20161105-11.12.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 kernel-default-4.12.14-122.272.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 libavahi-client3-0.6.32-32.33.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 libavahi-common3-0.6.32-32.33.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 libcurl4-8.0.1-11.108.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 libgcrypt20-1.6.1-16.86.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 libgnutls30-3.4.17-8.20.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 libopenssl1_0_0-1.0.2p-3.98.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 libopenssl1_1-1.1.1d-2.119.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 libpolkit0-0.113-5.30.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 libpython2_7-1_0-2.7.18-33.53.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 libpython3_4m1_0-3.4.10-25.158.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 libpython3_6m1_0-3.6.15-89.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 libsqlite3-0-3.50.2-9.41.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 libssh-config-0.9.8-3.18.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 libssh4-0.9.8-3.18.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 libxml2-2-2.9.4-46.90.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 net-tools-1.60-765.15.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 openssl-1_0_0-1.0.2p-3.98.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 pam-1.1.8-24.77.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 polkit-0.113-5.30.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 python-2.7.18-33.53.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 python-base-2.7.18-33.53.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 python-xml-2.7.18-33.53.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 python3-3.4.10-25.158.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 python3-base-3.4.10-25.158.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 python3-urllib3-1.25.10-3.43.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 python36-base-3.6.15-89.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 regionServiceClientConfigGCE-5.0.0-5.21.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 rsync-3.1.3-3.31.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 samba-client-libs-4.15.13+git.659.be30c436f5a-3.96.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 samba-libs-4.15.13+git.659.be30c436f5a-3.96.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 sqlite3-tcl-3.50.2-9.41.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 vim-9.1.1629-17.51.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 vim-data-common-9.1.1629-17.51.1 as a component of Public Cloud Image google/sles-12-sp5-v20251010-x86-64 In the Linux kernel, the following vulnerability has been resolved: kyber: fix out of bounds access when preempted __blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and passes the hctx to ->bio_merge(). kyber_bio_merge() then gets the ctx for the current CPU again and uses that to get the corresponding Kyber context in the passed hctx. However, the thread may be preempted between the two calls to blk_mq_get_ctx(), and the ctx returned the second time may no longer correspond to the passed hctx. This "works" accidentally most of the time, but it can cause us to read garbage if the second ctx came from an hctx with more ctx's than the first one (i.e., if ctx->index_hw[hctx->type] > hctx->nr_ctx). This manifested as this UBSAN array index out of bounds error reported by Jakub: UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type 'long unsigned int [128]' Call Trace: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34 queued_spin_lock_slowpath+0x476/0x480 do_raw_spin_lock+0x1c2/0x1d0 kyber_bio_merge+0x112/0x180 blk_mq_submit_bio+0x1f5/0x1100 submit_bio_noacct+0x7b0/0x870 submit_bio+0xc2/0x3a0 btrfs_map_bio+0x4f0/0x9d0 btrfs_submit_data_bio+0x24e/0x310 submit_one_bio+0x7f/0xb0 submit_extent_page+0xc4/0x440 __extent_writepage_io+0x2b8/0x5e0 __extent_writepage+0x28d/0x6e0 extent_write_cache_pages+0x4d7/0x7a0 extent_writepages+0xa2/0x110 do_writepages+0x8f/0x180 __writeback_single_inode+0x99/0x7f0 writeback_sb_inodes+0x34e/0x790 __writeback_inodes_wb+0x9e/0x120 wb_writeback+0x4d2/0x660 wb_workfn+0x64d/0xa10 process_one_work+0x53a/0xa80 worker_thread+0x69/0x5b0 kthread+0x20b/0x240 ret_from_fork+0x1f/0x30 Only Kyber uses the hctx, so fix it by passing the request_queue to ->bio_merge() instead. BFQ and mq-deadline just use that, and Kyber can map the queues itself to avoid the mismatch. CVE-2021-46984 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock when cloning inline extents and using qgroups There are a few exceptional cases where cloning an inline extent needs to copy the inline extent data into a page of the destination inode. When this happens, we end up starting a transaction while having a dirty page for the destination inode and while having the range locked in the destination's inode iotree too. Because when reserving metadata space for a transaction we may need to flush existing delalloc in case there is not enough free space, we have a mechanism in place to prevent a deadlock, which was introduced in commit 3d45f221ce627d ("btrfs: fix deadlock when cloning inline extent and low on free metadata space"). However when using qgroups, a transaction also reserves metadata qgroup space, which can also result in flushing delalloc in case there is not enough available space at the moment. When this happens we deadlock, since flushing delalloc requires locking the file range in the inode's iotree and the range was already locked at the very beginning of the clone operation, before attempting to start the transaction. When this issue happens, stack traces like the following are reported: [72747.556262] task:kworker/u81:9 state:D stack: 0 pid: 225 ppid: 2 flags:0x00004000 [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142) [72747.556271] Call Trace: [72747.556273] __schedule+0x296/0x760 [72747.556277] schedule+0x3c/0xa0 [72747.556279] io_schedule+0x12/0x40 [72747.556284] __lock_page+0x13c/0x280 [72747.556287] ? generic_file_readonly_mmap+0x70/0x70 [72747.556325] extent_write_cache_pages+0x22a/0x440 [btrfs] [72747.556331] ? __set_page_dirty_nobuffers+0xe7/0x160 [72747.556358] ? set_extent_buffer_dirty+0x5e/0x80 [btrfs] [72747.556362] ? update_group_capacity+0x25/0x210 [72747.556366] ? cpumask_next_and+0x1a/0x20 [72747.556391] extent_writepages+0x44/0xa0 [btrfs] [72747.556394] do_writepages+0x41/0xd0 [72747.556398] __writeback_single_inode+0x39/0x2a0 [72747.556403] writeback_sb_inodes+0x1ea/0x440 [72747.556407] __writeback_inodes_wb+0x5f/0xc0 [72747.556410] wb_writeback+0x235/0x2b0 [72747.556414] ? get_nr_inodes+0x35/0x50 [72747.556417] wb_workfn+0x354/0x490 [72747.556420] ? newidle_balance+0x2c5/0x3e0 [72747.556424] process_one_work+0x1aa/0x340 [72747.556426] worker_thread+0x30/0x390 [72747.556429] ? create_worker+0x1a0/0x1a0 [72747.556432] kthread+0x116/0x130 [72747.556435] ? kthread_park+0x80/0x80 [72747.556438] ret_from_fork+0x1f/0x30 [72747.566958] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs] [72747.566961] Call Trace: [72747.566964] __schedule+0x296/0x760 [72747.566968] ? finish_wait+0x80/0x80 [72747.566970] schedule+0x3c/0xa0 [72747.566995] wait_extent_bit.constprop.68+0x13b/0x1c0 [btrfs] [72747.566999] ? finish_wait+0x80/0x80 [72747.567024] lock_extent_bits+0x37/0x90 [btrfs] [72747.567047] btrfs_invalidatepage+0x299/0x2c0 [btrfs] [72747.567051] ? find_get_pages_range_tag+0x2cd/0x380 [72747.567076] __extent_writepage+0x203/0x320 [btrfs] [72747.567102] extent_write_cache_pages+0x2bb/0x440 [btrfs] [72747.567106] ? update_load_avg+0x7e/0x5f0 [72747.567109] ? enqueue_entity+0xf4/0x6f0 [72747.567134] extent_writepages+0x44/0xa0 [btrfs] [72747.567137] ? enqueue_task_fair+0x93/0x6f0 [72747.567140] do_writepages+0x41/0xd0 [72747.567144] __filemap_fdatawrite_range+0xc7/0x100 [72747.567167] btrfs_run_delalloc_work+0x17/0x40 [btrfs] [72747.567195] btrfs_work_helper+0xc2/0x300 [btrfs] [72747.567200] process_one_work+0x1aa/0x340 [72747.567202] worker_thread+0x30/0x390 [72747.567205] ? create_worker+0x1a0/0x1a0 [72747.567208] kthread+0x116/0x130 [72747.567211] ? kthread_park+0x80/0x80 [72747.567214] ret_from_fork+0x1f/0x30 [72747.569686] task:fsstress state:D stack: ---truncated--- CVE-2021-46987 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Update error handler for UCTX and UMEM In the fast unload flow, the device state is set to internal error, which indicates that the driver started the destroy process. In this case, when a destroy command is being executed, it should return MLX5_CMD_STAT_OK. Fix MLX5_CMD_OP_DESTROY_UCTX and MLX5_CMD_OP_DESTROY_UMEM to return OK instead of EIO. This fixes a call trace in the umem release process - [ 2633.536695] Call Trace: [ 2633.537518] ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs] [ 2633.538596] remove_client_context+0x8b/0xd0 [ib_core] [ 2633.539641] disable_device+0x8c/0x130 [ib_core] [ 2633.540615] __ib_unregister_device+0x35/0xa0 [ib_core] [ 2633.541640] ib_unregister_device+0x21/0x30 [ib_core] [ 2633.542663] __mlx5_ib_remove+0x38/0x90 [mlx5_ib] [ 2633.543640] auxiliary_bus_remove+0x1e/0x30 [auxiliary] [ 2633.544661] device_release_driver_internal+0x103/0x1f0 [ 2633.545679] bus_remove_device+0xf7/0x170 [ 2633.546640] device_del+0x181/0x410 [ 2633.547606] mlx5_rescan_drivers_locked.part.10+0x63/0x160 [mlx5_core] [ 2633.548777] mlx5_unregister_device+0x27/0x40 [mlx5_core] [ 2633.549841] mlx5_uninit_one+0x21/0xc0 [mlx5_core] [ 2633.550864] remove_one+0x69/0xe0 [mlx5_core] [ 2633.551819] pci_device_remove+0x3b/0xc0 [ 2633.552731] device_release_driver_internal+0x103/0x1f0 [ 2633.553746] unbind_store+0xf6/0x130 [ 2633.554657] kernfs_fop_write+0x116/0x190 [ 2633.555567] vfs_write+0xa5/0x1a0 [ 2633.556407] ksys_write+0x4f/0xb0 [ 2633.557233] do_syscall_64+0x5b/0x1a0 [ 2633.558071] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 2633.559018] RIP: 0033:0x7f9977132648 [ 2633.559821] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 55 6f 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55 [ 2633.562332] RSP: 002b:00007fffb1a83888 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 2633.563472] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f9977132648 [ 2633.564541] RDX: 000000000000000c RSI: 000055b90546e230 RDI: 0000000000000001 [ 2633.565596] RBP: 000055b90546e230 R08: 00007f9977406860 R09: 00007f9977a54740 [ 2633.566653] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f99774056e0 [ 2633.567692] R13: 000000000000000c R14: 00007f9977400880 R15: 000000000000000c [ 2633.568725] ---[ end trace 10b4fe52945e544d ]--- CVE-2021-47212 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: ptp: Fix possible memory leak in ptp_clock_register() I got memory leak as follows when doing fault injection test: unreferenced object 0xffff88800906c618 (size 8): comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s) hex dump (first 8 bytes): 70 74 70 30 00 00 00 00 ptp0.... backtrace: [<00000000312ed458>] __kmalloc_track_caller+0x19f/0x3a0 [<0000000079f6e2ff>] kvasprintf+0xb5/0x150 [<0000000026aae54f>] kvasprintf_const+0x60/0x190 [<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150 [<000000004e35abdd>] dev_set_name+0xc0/0x100 [<00000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp] [<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33] When posix_clock_register() returns an error, the name allocated in dev_set_name() will be leaked, the put_device() should be used to give up the device reference, then the name will be freed in kobject_cleanup() and other memory will be freed in ptp_clock_release(). CVE-2021-47455 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: serial: core: fix transmit-buffer reset and memleak Commit 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") converted serial core to use tty_port_close() but failed to notice that the transmit buffer still needs to be freed on final close. Not freeing the transmit buffer means that the buffer is no longer cleared on next open so that any ioctl() waiting for the buffer to drain might wait indefinitely (e.g. on termios changes) or that stale data can end up being transmitted in case tx is restarted. Furthermore, the buffer of any port that has been opened would leak on driver unbind. Note that the port lock is held when clearing the buffer pointer due to the ldisc race worked around by commit a5ba1d95e46e ("uart: fix race between uart_put_char() and uart_shutdown()"). Also note that the tty-port shutdown() callback is not called for console ports so it is not strictly necessary to free the buffer page after releasing the lock (cf. d72402145ace ("tty/serial: do not free trasnmit buffer page under port lock")). CVE-2021-47527 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate A use-after-free flaw was found in the Linux kernel's Atheros wireless adapter driver in the way a user forces the ath9k_htc_wait_for_target function to fail with some input messages. This flaw allows a local user to crash or potentially escalate their privileges on the system. CVE-2022-1679 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important 7.2 AV:L/AC:L/Au:N/C:C/I:C/A:C In the Linux kernel, the following vulnerability has been resolved: scsi: target: Fix WRITE_SAME No Data Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer that gets written out. If this bit is set using commands like "sg_write_same --ndob" we will crash in target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal WRITE SAME with no data buffer. CVE-2022-21546 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate It was discovered that a nft object or expression could reference a nft set on a different nft table, leading to a use-after-free once that table was deleted. CVE-2022-2586 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate An incorrect read request flaw was found in the Infrared Transceiver USB driver in the Linux kernel. This issue occurs when a user attaches a malicious USB device. A local user could use this flaw to starve the resources, causing denial of service or potentially crashing the system. CVE-2022-3903 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate A use-after-free flaw was found in Linux kernel before 5.19.2. This issue occurs in cmd_hdl_filter in drivers/staging/rtl8712/rtl8712_cmd.c, allowing an attacker to launch a local denial of service attack and gain escalation of privileges. CVE-2022-4095 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important A flaw was found in the Linux kernel's Layer 2 Tunneling Protocol (L2TP). A missing lock when clearing sk_user_data can lead to a race condition and NULL pointer dereference. A local user could use this flaw to potentially crash the system causing a denial of service. CVE-2022-4129 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate A flaw incorrect access control in the Linux kernel USB core subsystem was found in the way user attaches usb device. A local user could use this flaw to crash the system. CVE-2022-4662 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Ignore multiple conn complete events When one of the three connection complete events is received multiple times for the same handle, the device is registered multiple times which leads to memory corruptions. Therefore, consequent events for a single connection are ignored. The conn->state can hold different values, therefore HCI_CONN_HANDLE_UNSET is introduced to identify new connections. To make sure the events do not contain this or another invalid handle HCI_CONN_HANDLE_MAX and checks are introduced. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=215497 CVE-2022-49138 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: fix panic on out-of-bounds guest IRQ As guest_irq is coming from KVM_IRQFD API call, it may trigger crash in svm_update_pi_irte() due to out-of-bounds: crash> bt PID: 22218 TASK: ffff951a6ad74980 CPU: 73 COMMAND: "vcpu8" #0 [ffffb1ba6707fa40] machine_kexec at ffffffff8565b397 #1 [ffffb1ba6707fa90] __crash_kexec at ffffffff85788a6d #2 [ffffb1ba6707fb58] crash_kexec at ffffffff8578995d #3 [ffffb1ba6707fb70] oops_end at ffffffff85623c0d #4 [ffffb1ba6707fb90] no_context at ffffffff856692c9 #5 [ffffb1ba6707fbf8] exc_page_fault at ffffffff85f95b51 #6 [ffffb1ba6707fc50] asm_exc_page_fault at ffffffff86000ace [exception RIP: svm_update_pi_irte+227] RIP: ffffffffc0761b53 RSP: ffffb1ba6707fd08 RFLAGS: 00010086 RAX: ffffb1ba6707fd78 RBX: ffffb1ba66d91000 RCX: 0000000000000001 RDX: 00003c803f63f1c0 RSI: 000000000000019a RDI: ffffb1ba66db2ab8 RBP: 000000000000019a R8: 0000000000000040 R9: ffff94ca41b82200 R10: ffffffffffffffcf R11: 0000000000000001 R12: 0000000000000001 R13: 0000000000000001 R14: ffffffffffffffcf R15: 000000000000005f ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb1ba6707fdb8] kvm_irq_routing_update at ffffffffc09f19a1 [kvm] #8 [ffffb1ba6707fde0] kvm_set_irq_routing at ffffffffc09f2133 [kvm] #9 [ffffb1ba6707fe18] kvm_vm_ioctl at ffffffffc09ef544 [kvm] RIP: 00007f143c36488b RSP: 00007f143a4e04b8 RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 00007f05780041d0 RCX: 00007f143c36488b RDX: 00007f05780041d0 RSI: 000000004008ae6a RDI: 0000000000000020 RBP: 00000000000004e8 R8: 0000000000000008 R9: 00007f05780041e0 R10: 00007f0578004560 R11: 0000000000000246 R12: 00000000000004e0 R13: 000000000000001a R14: 00007f1424001c60 R15: 00007f0578003bc0 ORIG_RAX: 0000000000000010 CS: 0033 SS: 002b Vmx have been fix this in commit 3a8b0677fc61 (KVM: VMX: Do not BUG() on out-of-bounds guest IRQ), so we can just copy source from that to fix this. CVE-2022-49154 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. CVE-2022-49319 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu: fix possible null-ptr-deref in arm_smmu_device_probe() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. CVE-2022-49323 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: avoid skb access on nf_stolen When verdict is NF_STOLEN, the skb might have been freed. When tracing is enabled, this can result in a use-after-free: 1. access to skb->nf_trace 2. access to skb->mark 3. computation of trace id 4. dump of packet payload To avoid 1, keep a cached copy of skb->nf_trace in the trace state struct. Refresh this copy whenever verdict is != STOLEN. Avoid 2 by skipping skb->mark access if verdict is STOLEN. 3 is avoided by precomputing the trace id. Only dump the packet when verdict is not "STOLEN". CVE-2022-49622 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() In an unlikely (and probably wrong?) case that the 'ppi' parameter of ata_host_alloc_pinfo() points to an array starting with a NULL pointer, there's going to be a kernel oops as the 'pi' local variable won't get reassigned from the initial value of NULL. Initialize 'pi' instead to '&ata_dummy_port_info' to fix the possible kernel oops for good... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. CVE-2022-49731 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent bpf program recursion for raw tracepoint probes We got report from sysbot [1] about warnings that were caused by bpf program attached to contention_begin raw tracepoint triggering the same tracepoint by using bpf_trace_printk helper that takes trace_printk_lock lock. Call Trace: <TASK> ? trace_event_raw_event_bpf_trace_printk+0x5f/0x90 bpf_trace_printk+0x2b/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 __unfreeze_partials+0x5b/0x160 ... The can be reproduced by attaching bpf program as raw tracepoint on contention_begin tracepoint. The bpf prog calls bpf_trace_printk helper. Then by running perf bench the spin lock code is forced to take slow path and call contention_begin tracepoint. Fixing this by skipping execution of the bpf program if it's already running, Using bpf prog 'active' field, which is being currently used by trampoline programs for the same reason. Moving bpf_prog_inc_misses_counter to syscall.c because trampoline.c is compiled in just for CONFIG_BPF_JIT option. [1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t CVE-2022-49764 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: 9p: trans_fd/p9_conn_cancel: drop client lock earlier syzbot reported a double-lock here and we no longer need this lock after requests have been moved off to local list: just drop the lock earlier. CVE-2022-49768 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus() If device_register() fails in tcm_loop_setup_hba_bus(), the name allocated by dev_set_name() need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(). The 'tl_hba' will be freed in tcm_loop_release_adapter(), so it don't need goto error label in this case. CVE-2022-49780 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: kcm: close race conditions on sk_receive_queue sk->sk_receive_queue is protected by skb queue lock, but for KCM sockets its RX path takes mux->rx_lock to protect more than just skb queue. However, kcm_recvmsg() still only grabs the skb queue lock, so race conditions still exist. We can teach kcm_recvmsg() to grab mux->rx_lock too but this would introduce a potential performance regression as struct kcm_mux can be shared by multiple KCM sockets. So we have to enforce skb queue lock in requeue_rx_msgs() and handle skb peek case carefully in kcm_wait_data(). Fortunately, skb_recv_datagram() already handles it nicely and is widely used by other sockets, we can just switch to skb_recv_datagram() after getting rid of the unnecessary sock lock in kcm_recvmsg() and kcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets, so it is safe to get rid of this check too. I ran the original syzbot reproducer for 30 min without seeing any issue. CVE-2022-49814 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix BUG_ON() when directory entry has invalid rec_len The rec_len field in the directory entry has to be a multiple of 4. A corrupted filesystem image can be used to hit a BUG() in ext4_rec_len_to_disk(), called from make_indexed_dir(). ------------[ cut here ]------------ kernel BUG at fs/ext4/ext4.h:2413! ... RIP: 0010:make_indexed_dir+0x53f/0x5f0 ... Call Trace: <TASK> ? add_dirent_to_buf+0x1b2/0x200 ext4_add_entry+0x36e/0x480 ext4_add_nondir+0x2b/0xc0 ext4_create+0x163/0x200 path_openat+0x635/0xe90 do_filp_open+0xb4/0x160 ? __create_object.isra.0+0x1de/0x3b0 ? _raw_spin_unlock+0x12/0x30 do_sys_openat2+0x91/0x150 __x64_sys_open+0x6c/0xa0 do_syscall_64+0x3c/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The fix simply adds a call to ext4_check_dir_entry() to validate the directory entry, returning -EFSCORRUPTED if the entry is invalid. CVE-2022-49879 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix memory leak in query_regdb_file() In the function query_regdb_file() the alpha2 parameter is duplicated using kmemdup() and subsequently freed in regdb_fw_cb(). However, request_firmware_nowait() can fail without calling regdb_fw_cb() and thus leak memory. CVE-2022-49881 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipvs: fix WARNING in ip_vs_app_net_cleanup() During the initialization of ip_vs_app_net_init(), if file ip_vs_app fails to be created, the initialization is successful by default. Therefore, the ip_vs_app file doesn't be found during the remove in ip_vs_app_net_cleanup(). It will cause WRNING. The following is the stack information: name 'ip_vs_app' WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460 Modules linked in: Workqueue: netns cleanup_net RIP: 0010:remove_proc_entry+0x389/0x460 Call Trace: <TASK> ops_exit_list+0x125/0x170 cleanup_net+0x4ea/0xb00 process_one_work+0x9bf/0x1710 worker_thread+0x665/0x1080 kthread+0x2e4/0x3a0 ret_from_fork+0x1f/0x30 </TASK> CVE-2022-49917 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: sched: Fix use after free in red_enqueue() We can't use "skb" again after passing it to qdisc_enqueue(). This is basically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb len before calling child enqueue"). CVE-2022-49921 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Fix UAF in ieee80211_scan_rx() ieee80211_scan_rx() tries to access scan_req->flags after a null check, but a UAF is observed when the scan is completed and __ieee80211_scan_completed() executes, which then calls cfg80211_scan_done() leading to the freeing of scan_req. Since scan_req is rcu_dereference()'d, prevent the racing in __ieee80211_scan_completed() by ensuring that from mac80211's POV it is no longer accessed from an RCU read critical section before we call cfg80211_scan_done(). CVE-2022-49934 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: cifs: fix small mempool leak in SMB2_negotiate() In some cases of failure (dialect mismatches) in SMB2_negotiate(), after the request is sent, the checks would return -EIO when they should be rather setting rc = -EIO and jumping to neg_exit to free the response buffer from mempool. CVE-2022-49938 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 low In the Linux kernel, the following vulnerability has been resolved: vt: Clear selection before changing the font When changing the console font with ioctl(KDFONTOP) the new font size can be bigger than the previous font. A previous selection may thus now be outside of the new screen size and thus trigger out-of-bounds accesses to graphics memory if the selection is removed in vc_do_resize(). Prevent such out-of-memory accesses by dropping the selection before the various con_font_set() console handlers are called. CVE-2022-49948 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: Input: iforce - wake up after clearing IFORCE_XMIT_RUNNING flag syzbot is reporting hung task at __input_unregister_device() [1], for iforce_close() waiting at wait_event_interruptible() with dev->mutex held is blocking input_disconnect_device() from __input_unregister_device(). It seems that the cause is simply that commit c2b27ef672992a20 ("Input: iforce - wait for command completion when closing the device") forgot to call wake_up() after clear_bit(). Fix this problem by introducing a helper that calls clear_bit() followed by wake_up_all(). CVE-2022-49954 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: kcm: fix strp_init() order and cleanup strp_init() is called just a few lines above this csk->sk_user_data check, it also initializes strp->work etc., therefore, it is unnecessary to call strp_done() to cancel the freshly initialized work. And if sk_user_data is already used by KCM, psock->strp should not be touched, particularly strp->work state, so we need to move strp_init() after the csk->sk_user_data check. This also makes a lockdep warning reported by syzbot go away. CVE-2022-49957 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a data-race around bpf_jit_limit. While reading bpf_jit_limit, it can be changed concurrently via sysctl, WRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limit is long, so we need to add a paired READ_ONCE() to avoid load-tearing. CVE-2022-49967 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: clear optc underflow before turn off odm clock [Why] After ODM clock off, optc underflow bit will be kept there always and clear not work. We need to clear that before clock off. [How] Clear that if have when clock off. CVE-2022-49969 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf: Don't redirect packets with invalid pkt_len Syzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout any skbs, that is, the flow->head is null. The root cause, as the [2] says, is because that bpf_prog_test_run_skb() run a bpf prog which redirects empty skbs. So we should determine whether the length of the packet modified by bpf prog or others like bpf_prog_test is valid before forwarding it directly. CVE-2022-49975 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead ftrace_startup does not remove ops from ftrace_ops_list when ftrace_startup_enable fails: register_ftrace_function ftrace_startup __register_ftrace_function ... add_ftrace_ops(&ftrace_ops_list, ops) ... ... ftrace_startup_enable // if ftrace failed to modify, ftrace_disabled is set to 1 ... return 0 // ops is in the ftrace_ops_list. When ftrace_disabled = 1, unregister_ftrace_function simply returns without doing anything: unregister_ftrace_function ftrace_shutdown if (unlikely(ftrace_disabled)) return -ENODEV; // return here, __unregister_ftrace_function is not executed, // as a result, ops is still in the ftrace_ops_list __unregister_ftrace_function ... If ops is dynamically allocated, it will be free later, in this case, is_ftrace_trampoline accesses NULL pointer: is_ftrace_trampoline ftrace_ops_trampoline do_for_each_ftrace_op(op, ftrace_ops_list) // OOPS! op may be NULL! Syzkaller reports as follows: [ 1203.506103] BUG: kernel NULL pointer dereference, address: 000000000000010b [ 1203.508039] #PF: supervisor read access in kernel mode [ 1203.508798] #PF: error_code(0x0000) - not-present page [ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0 [ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI [ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Tainted: G B W 5.10.0 #8 [ 1203.512324] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0 [ 1203.514644] Code: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 <48> 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00 [ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246 [ 1203.520092] RAX: 0000000000000000 RBX: 000000000000007b RCX: ffffffff8a331866 [ 1203.521469] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000000000000010b [ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df18b07 [ 1203.523550] R10: fffffbfff1be3160 R11: 0000000000000001 R12: 0000000000478399 [ 1203.524596] R13: 0000000000000000 R14: ffff888145088000 R15: 0000000000000008 [ 1203.525634] FS: 00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000 [ 1203.526801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1203.527626] CR2: 000000000000010b CR3: 0000000170e1e001 CR4: 00000000003706e0 [ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Therefore, when ftrace_startup_enable fails, we need to rollback registration process and remove ops from ftrace_ops_list. CVE-2022-49977 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: fbdev: fb_pm2fb: Avoid potential divide by zero error In `do_fb_ioctl()` of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will be copied from user, then go through `fb_set_var()` and `info->fbops->fb_check_var()` which could may be `pm2fb_check_var()`. Along the path, `var->pixclock` won't be modified. This function checks whether reciprocal of `var->pixclock` is too high. If `var->pixclock` is zero, there will be a divide by zero error. So, it is necessary to check whether denominator is zero to avoid crash. As this bug is found by Syzkaller, logs are listed below. divide error in pm2fb_check_var Call Trace: <TASK> fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 CVE-2022-49978 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: USB: gadget: Fix use-after-free Read in usb_udc_uevent() The syzbot fuzzer found a race between uevent callbacks and gadget driver unregistration that can cause a use-after-free bug: --------------------------------------------------------------- BUG: KASAN: use-after-free in usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732 Read of size 8 at addr ffff888078ce2050 by task udevd/2968 CPU: 1 PID: 2968 Comm: udevd Not tainted 5.19.0-rc4-next-20220628-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/29/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report+0xbe/0x1f0 mm/kasan/report.c:495 usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732 dev_uevent+0x290/0x770 drivers/base/core.c:2424 --------------------------------------------------------------- The bug occurs because usb_udc_uevent() dereferences udc->driver but does so without acquiring the udc_lock mutex, which protects this field. If the gadget driver is unbound from the udc concurrently with uevent processing, the driver structure may be accessed after it has been deallocated. To prevent the race, we make sure that the routine holds the mutex around the racing accesses. CVE-2022-49980 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: HID: hidraw: fix memory leak in hidraw_release() Free the buffered reports before deleting the list entry. BUG: memory leak unreferenced object 0xffff88810e72f180 (size 32): comm "softirq", pid 0, jiffies 4294945143 (age 16.080s) hex dump (first 32 bytes): 64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 d..j............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814ac6c3>] kmemdup+0x23/0x50 mm/util.c:128 [<ffffffff8357c1d2>] kmemdup include/linux/fortify-string.h:440 [inline] [<ffffffff8357c1d2>] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521 [<ffffffff8356ddad>] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992 [<ffffffff8356e41e>] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065 [<ffffffff835f0d3f>] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284 [<ffffffff82d3c7f9>] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670 [<ffffffff82d3cc26>] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747 [<ffffffff82ef1e14>] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988 [<ffffffff812f50a8>] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474 [<ffffffff812f5586>] expire_timers kernel/time/timer.c:1519 [inline] [<ffffffff812f5586>] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790 [<ffffffff812f56e4>] __run_timers kernel/time/timer.c:1768 [inline] [<ffffffff812f56e4>] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803 [<ffffffff848000e6>] __do_softirq+0xe6/0x2ea kernel/softirq.c:571 [<ffffffff81246db0>] invoke_softirq kernel/softirq.c:445 [inline] [<ffffffff81246db0>] __irq_exit_rcu kernel/softirq.c:650 [inline] [<ffffffff81246db0>] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662 [<ffffffff84574f02>] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106 [<ffffffff84600c8b>] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649 [<ffffffff8458a070>] native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline] [<ffffffff8458a070>] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline] [<ffffffff8458a070>] acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline] [<ffffffff8458a070>] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processor_idle.c:554 CVE-2022-49981 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it doesn't need to make forward progress under memory pressure. Marking this workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a non-WQ_MEM_RECLAIM workqueue. In the current state it causes the following warning: [ 14.506347] ------------[ cut here ]------------ [ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn [ 14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130 [ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu [ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [ 14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun [ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130 <-snip-> [ 14.506408] Call Trace: [ 14.506412] __flush_work+0xf1/0x1c0 [ 14.506414] __cancel_work_timer+0x12f/0x1b0 [ 14.506417] ? kernfs_put+0xf0/0x190 [ 14.506418] cancel_delayed_work_sync+0x13/0x20 [ 14.506420] disk_block_events+0x78/0x80 [ 14.506421] del_gendisk+0x3d/0x2f0 [ 14.506423] sr_remove+0x28/0x70 [ 14.506427] device_release_driver_internal+0xef/0x1c0 [ 14.506428] device_release_driver+0x12/0x20 [ 14.506429] bus_remove_device+0xe1/0x150 [ 14.506431] device_del+0x167/0x380 [ 14.506432] __scsi_remove_device+0x11d/0x150 [ 14.506433] scsi_remove_device+0x26/0x40 [ 14.506434] storvsc_remove_lun+0x40/0x60 [ 14.506436] process_one_work+0x209/0x400 [ 14.506437] worker_thread+0x34/0x400 [ 14.506439] kthread+0x121/0x140 [ 14.506440] ? process_one_work+0x400/0x400 [ 14.506441] ? kthread_park+0x90/0x90 [ 14.506443] ret_from_fork+0x35/0x40 [ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]--- CVE-2022-49986 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: md: call __md_stop_writes in md_stop From the link [1], we can see raid1d was running even after the path raid_dtr -> md_stop -> __md_stop. Let's stop write first in destructor to align with normal md-raid to fix the KASAN issue. [1]. https://lore.kernel.org/linux-raid/CAPhsuW5gc4AakdGNdF8ubpezAuDLFOYUO_sfMZcec6hQFm8nhg@mail.gmail.com/T/#m7f12bf90481c02c6d2da68c64aeed4779b7df74a CVE-2022-49987 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: s390: fix double free of GS and RI CBs on fork() failure The pointers for guarded storage and runtime instrumentation control blocks are stored in the thread_struct of the associated task. These pointers are initially copied on fork() via arch_dup_task_struct() and then cleared via copy_thread() before fork() returns. If fork() happens to fail after the initial task dup and before copy_thread(), the newly allocated task and associated thread_struct memory are freed via free_task() -> arch_release_task_struct(). This results in a double free of the guarded storage and runtime info structs because the fields in the failed task still refer to memory associated with the source task. This problem can manifest as a BUG_ON() in set_freepointer() (with CONFIG_SLAB_FREELIST_HARDENED enabled) or KASAN splat (if enabled) when running trinity syscall fuzz tests on s390x. To avoid this problem, clear the associated pointer fields in arch_dup_task_struct() immediately after the new task is copied. Note that the RI flag is still cleared in copy_thread() because it resides in thread stack memory and that is where stack info is copied. CVE-2022-49990 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: loop: Check for overflow while configuring loop The userspace can configure a loop using an ioctl call, wherein a configuration of type loop_config is passed (see lo_ioctl()'s case on line 1550 of drivers/block/loop.c). This proceeds to call loop_configure() which in turn calls loop_set_status_from_info() (see line 1050 of loop.c), passing &config->info which is of type loop_info64*. This function then sets the appropriate values, like the offset. loop_device has lo_offset of type loff_t (see line 52 of loop.c), which is typdef-chained to long long, whereas loop_info64 has lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h). The function directly copies offset from info to the device as follows (See line 980 of loop.c): lo->lo_offset = info->lo_offset; This results in an overflow, which triggers a warning in iomap_iter() due to a call to iomap_iter_done() which has: WARN_ON_ONCE(iter->iomap.offset > iter->pos); Thus, check for negative value during loop_set_status_from_info(). Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e CVE-2022-49993 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: xfrm: fix refcount leak in __xfrm_policy_check() The issue happens on an error path in __xfrm_policy_check(). When the fetching process of the object `pols[1]` fails, the function simply returns 0, forgetting to decrement the reference count of `pols[0]`, which is incremented earlier by either xfrm_sk_policy_lookup() or xfrm_policy_lookup(). This may result in memory leaks. Fix it by decreasing the reference count of `pols[0]` in that path. CVE-2022-50007 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: kprobes: don't call disarm_kprobe() for disabled kprobes The assumption in __disable_kprobe() is wrong, and it could try to disarm an already disarmed kprobe and fire the WARN_ONCE() below. [0] We can easily reproduce this issue. 1. Write 0 to /sys/kernel/debug/kprobes/enabled. # echo 0 > /sys/kernel/debug/kprobes/enabled 2. Run execsnoop. At this time, one kprobe is disabled. # /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE] 3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes kprobes_all_disarmed to false but does not arm the disabled kprobe. # echo 1 > /sys/kernel/debug/kprobes/enabled # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE] 4. Kill execsnoop, when __disable_kprobe() calls disarm_kprobe() for the disabled kprobe and hits the WARN_ONCE() in __disarm_kprobe_ftrace(). # fg /usr/share/bcc/tools/execsnoop ^C Actually, WARN_ONCE() is fired twice, and __unregister_kprobe_top() misses some cleanups and leaves the aggregated kprobe in the hash table. Then, __unregister_trace_kprobe() initialises tk->rp.kp.list and creates an infinite loop like this. aggregated kprobe.list -> kprobe.list -. ^ | '.__.' In this situation, these commands fall into the infinite loop and result in RCU stall or soft lockup. cat /sys/kernel/debug/kprobes/list : show_kprobe_addr() enters into the infinite loop with RCU. /usr/share/bcc/tools/execsnoop : warn_kprobe_rereg() holds kprobe_mutex, and __get_valid_kprobe() is stuck in the loop. To avoid the issue, make sure we don't call disarm_kprobe() for disabled kprobes. [0] Failed to disarm kprobe-ftrace at __x64_sys_execve+0x0/0x40 (error -2) WARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130 __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Modules linked in: ena CPU: 6 PID: 2460 Comm: execsnoop Not tainted 5.19.0+ #28 Hardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017 RIP: 0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Code: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94 RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001 RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff RBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff R10: 0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40 R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 0000000000000000 FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> __disable_kprobe (kernel/kprobes.c:1716) disable_kprobe (kernel/kprobes.c:2392) __disable_trace_kprobe (kernel/trace/trace_kprobe.c:340) disable_trace_kprobe (kernel/trace/trace_kprobe.c:429) perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168) perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295) _free_event (kernel/events/core.c:4971) perf_event_release_kernel (kernel/events/core.c:5176) perf_release (kernel/events/core.c:5186) __fput (fs/file_table.c:321) task_work_run (./include/linux/ ---truncated--- CVE-2022-50008 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/64: Init jump labels before parse_early_param() On 64-bit, calling jump_label_init() in setup_feature_keys() is too late because static keys may be used in subroutines of parse_early_param() which is again subroutine of early_init_devtree(). For example booting with "threadirqs": static_key_enable_cpuslocked(): static key '0xc000000002953260' used before call to jump_label_init() WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120 ... NIP static_key_enable_cpuslocked+0xfc/0x120 LR static_key_enable_cpuslocked+0xf8/0x120 Call Trace: static_key_enable_cpuslocked+0xf8/0x120 (unreliable) static_key_enable+0x30/0x50 setup_forced_irqthreads+0x28/0x40 do_early_param+0xa0/0x108 parse_args+0x290/0x4e0 parse_early_options+0x48/0x5c parse_early_param+0x58/0x84 early_init_devtree+0xd4/0x518 early_setup+0xb4/0x214 So call jump_label_init() just before parse_early_param() in early_init_devtree(). [mpe: Add call trace to change log and minor wording edits.] CVE-2022-50012 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: avoid resizing to a partial cluster size This patch avoids an attempt to resize the filesystem to an unaligned cluster boundary. An online resize to a size that is not integral to cluster size results in the last iteration attempting to grow the fs by a negative amount, which trips a BUG_ON and leaves the fs with a corrupted in-memory superblock. CVE-2022-50020 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: drivers:md:fix a potential use-after-free bug In line 2884, "raid5_release_stripe(sh);" drops the reference to sh and may cause sh to be released. However, sh is subsequently used in lines 2886 "if (sh->batch_head && sh != sh->batch_head)". This may result in an use-after-free bug. It can be fixed by moving "raid5_release_stripe(sh);" to the bottom of the function. CVE-2022-50022 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: cxl: Fix a memory leak in an error handling path A bitmap_zalloc() must be balanced by a corresponding bitmap_free() in the error handling path of afu_allocate_irqs(). CVE-2022-50025 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 low In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix possible memory leak when failing to issue CMF WQE There is no corresponding free routine if lpfc_sli4_issue_wqe fails to issue the CMF WQE in lpfc_issue_cmf_sync_wqe. If ret_val is non-zero, then free the iocbq request structure. CVE-2022-50027 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Prevent buffer overflow crashes in debugfs with malformed user input Malformed user input to debugfs results in buffer overflow crashes. Adapt input string lengths to fit within internal buffers, leaving space for NULL terminators. CVE-2022-50030 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: host: ohci-ppc-of: Fix refcount leak bug In ohci_hcd_ppc_of_probe(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore. CVE-2022-50033 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/pci: Fix get_phb_number() locking The recent change to get_phb_number() causes a DEBUG_ATOMIC_SLEEP warning on some systems: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 1 lock held by swapper/1: #0: c157efb0 (hose_spinlock){+.+.}-{2:2}, at: pcibios_alloc_controller+0x64/0x220 Preemption disabled at: [<00000000>] 0x0 CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0-yocto-standard+ #1 Call Trace: [d101dc90] [c073b264] dump_stack_lvl+0x50/0x8c (unreliable) [d101dcb0] [c0093b70] __might_resched+0x258/0x2a8 [d101dcd0] [c0d3e634] __mutex_lock+0x6c/0x6ec [d101dd50] [c0a84174] of_alias_get_id+0x50/0xf4 [d101dd80] [c002ec78] pcibios_alloc_controller+0x1b8/0x220 [d101ddd0] [c140c9dc] pmac_pci_init+0x198/0x784 [d101de50] [c140852c] discover_phbs+0x30/0x4c [d101de60] [c0007fd4] do_one_initcall+0x94/0x344 [d101ded0] [c1403b40] kernel_init_freeable+0x1a8/0x22c [d101df10] [c00086e0] kernel_init+0x34/0x160 [d101df30] [c001b334] ret_from_kernel_thread+0x5c/0x64 This is because pcibios_alloc_controller() holds hose_spinlock but of_alias_get_id() takes of_mutex which can sleep. The hose_spinlock protects the phb_bitmap, and also the hose_list, but it doesn't need to be held while get_phb_number() calls the OF routines, because those are only looking up information in the device tree. So fix it by having get_phb_number() take the hose_spinlock itself, only where required, and then dropping the lock before returning. pcibios_alloc_controller() then needs to take the lock again before the list_add() but that's safe, the order of the list is not important. CVE-2022-50045 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: iavf: Fix adminq error handling iavf_alloc_asq_bufs/iavf_alloc_arq_bufs allocates with dma_alloc_coherent memory for VF mailbox. Free DMA regions for both ASQ and ARQ in case error happens during configuration of ASQ/ARQ registers. Without this change it is possible to see when unloading interface: 74626.583369: dma_debug_device_change: device driver has pending DMA allocations while released from device [count=32] One of leaked entries details: [device address=0x0000000b27ff9000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as coherent] CVE-2022-50055 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: virtio_net: fix memory leak inside XPD_TX with mergeable When we call xdp_convert_buff_to_frame() to get xdpf, if it returns NULL, we should check if xdp_page was allocated by xdp_linearize_page(). If it is newly allocated, it should be freed here alone. Just like any other "goto err_xdp". CVE-2022-50065 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: atlantic: fix aq_vec index out of range error The final update statement of the for loop exceeds the array range, the dereference of self->aq_vec[i] is not checked and then leads to the index out of range error. Also fixed this kind of coding style in other for loop. [ 97.937604] UBSAN: array-index-out-of-bounds in drivers/net/ethernet/aquantia/atlantic/aq_nic.c:1404:48 [ 97.937607] index 8 is out of range for type 'aq_vec_s *[8]' [ 97.937608] CPU: 38 PID: 3767 Comm: kworker/u256:18 Not tainted 5.19.0+ #2 [ 97.937610] Hardware name: Dell Inc. Precision 7865 Tower/, BIOS 1.0.0 06/12/2022 [ 97.937611] Workqueue: events_unbound async_run_entry_fn [ 97.937616] Call Trace: [ 97.937617] <TASK> [ 97.937619] dump_stack_lvl+0x49/0x63 [ 97.937624] dump_stack+0x10/0x16 [ 97.937626] ubsan_epilogue+0x9/0x3f [ 97.937627] __ubsan_handle_out_of_bounds.cold+0x44/0x49 [ 97.937629] ? __scm_send+0x348/0x440 [ 97.937632] ? aq_vec_stop+0x72/0x80 [atlantic] [ 97.937639] aq_nic_stop+0x1b6/0x1c0 [atlantic] [ 97.937644] aq_suspend_common+0x88/0x90 [atlantic] [ 97.937648] aq_pm_suspend_poweroff+0xe/0x20 [atlantic] [ 97.937653] pci_pm_suspend+0x7e/0x1a0 [ 97.937655] ? pci_pm_suspend_noirq+0x2b0/0x2b0 [ 97.937657] dpm_run_callback+0x54/0x190 [ 97.937660] __device_suspend+0x14c/0x4d0 [ 97.937661] async_suspend+0x23/0x70 [ 97.937663] async_run_entry_fn+0x33/0x120 [ 97.937664] process_one_work+0x21f/0x3f0 [ 97.937666] worker_thread+0x4a/0x3c0 [ 97.937668] ? process_one_work+0x3f0/0x3f0 [ 97.937669] kthread+0xf0/0x120 [ 97.937671] ? kthread_complete_and_exit+0x20/0x20 [ 97.937672] ret_from_fork+0x22/0x30 [ 97.937676] </TASK> v2. fixed "warning: variable 'aq_vec' set but not used" v3. simplified a for loop CVE-2022-50066 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null Fixes a NULL pointer derefence bug triggered from tap driver. When tap_get_user calls virtio_net_hdr_to_skb the skb->dev is null (in tap.c skb->dev is set after the call to virtio_net_hdr_to_skb) virtio_net_hdr_to_skb calls dev_parse_header_protocol which needs skb->dev field to be valid. The line that trigers the bug is in dev_parse_header_protocol (dev is at offset 0x10 from skb and is stored in RAX register) if (!dev->header_ops || !dev->header_ops->parse_protocol) 22e1: mov 0x10(%rbx),%rax 22e5: mov 0x230(%rax),%rax Setting skb->dev before the call in tap.c fixes the issue. BUG: kernel NULL pointer dereference, address: 0000000000000230 RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap] Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48 RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010 RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300 RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8 R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6 FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0 Call Trace: tap_get_user+0x3f1/0x540 [tap] tap_sendmsg+0x56/0x362 [tap] ? get_tx_bufs+0xc2/0x1e0 [vhost_net] handle_tx_copy+0x114/0x670 [vhost_net] handle_tx+0xb0/0xe0 [vhost_net] handle_tx_kick+0x15/0x20 [vhost_net] vhost_worker+0x7b/0xc0 [vhost] ? vhost_vring_call_reset+0x40/0x40 [vhost] kthread+0xfa/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 CVE-2022-50073 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: tee: add overflow check in register_shm_helper() With special lengths supplied by user space, register_shm_helper() has an integer overflow when calculating the number of pages covered by a supplied user space memory region. This causes internal_get_user_pages_fast() a helper function of pin_user_pages_fast() to do a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Modules linked in: CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pc : internal_get_user_pages_fast+0x474/0xa80 Call trace: internal_get_user_pages_fast+0x474/0xa80 pin_user_pages_fast+0x24/0x4c register_shm_helper+0x194/0x330 tee_shm_register_user_buf+0x78/0x120 tee_ioctl+0xd0/0x11a0 __arm64_sys_ioctl+0xa8/0xec invoke_syscall+0x48/0x114 Fix this by adding an an explicit call to access_ok() in tee_shm_register_user_buf() to catch an invalid user space address early. CVE-2022-50080 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: fix warning in ext4_iomap_begin as race between bmap and write We got issue as follows: ------------[ cut here ]------------ WARNING: CPU: 3 PID: 9310 at fs/ext4/inode.c:3441 ext4_iomap_begin+0x182/0x5d0 RIP: 0010:ext4_iomap_begin+0x182/0x5d0 RSP: 0018:ffff88812460fa08 EFLAGS: 00010293 RAX: ffff88811f168000 RBX: 0000000000000000 RCX: ffffffff97793c12 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: ffff88812c669160 R08: ffff88811f168000 R09: ffffed10258cd20f R10: ffff88812c669077 R11: ffffed10258cd20e R12: 0000000000000001 R13: 00000000000000a4 R14: 000000000000000c R15: ffff88812c6691ee FS: 00007fd0d6ff3740(0000) GS:ffff8883af180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd0d6dda290 CR3: 0000000104a62000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iomap_apply+0x119/0x570 iomap_bmap+0x124/0x150 ext4_bmap+0x14f/0x250 bmap+0x55/0x80 do_vfs_ioctl+0x952/0xbd0 __x64_sys_ioctl+0xc6/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Above issue may happen as follows: bmap write bmap ext4_bmap iomap_bmap ext4_iomap_begin ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin ext4_prepare_inline_data ext4_create_inline_data ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); if (WARN_ON_ONCE(ext4_has_inline_data(inode))) ->trigger bug_on To solved above issue hold inode lock in ext4_bamp. CVE-2022-50082 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2022-50083 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm raid: fix address sanitizer warning in raid_status There is this warning when using a kernel with the address sanitizer and running this testsuite: https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi_raid ================================================================== BUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid] Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319 CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3.<snip> #1 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Call Trace: <TASK> dump_stack_lvl+0x6a/0x9c print_address_description.constprop.0+0x1f/0x1e0 print_report.cold+0x55/0x244 kasan_report+0xc9/0x100 raid_status+0x1747/0x2820 [dm_raid] dm_ima_measure_on_table_load+0x4b8/0xca0 [dm_mod] table_load+0x35c/0x630 [dm_mod] ctl_ioctl+0x411/0x630 [dm_mod] dm_ctl_ioctl+0xa/0x10 [dm_mod] __x64_sys_ioctl+0x12a/0x1a0 do_syscall_64+0x5b/0x80 The warning is caused by reading conf->max_nr_stripes in raid_status. The code in raid_status reads mddev->private, casts it to struct r5conf and reads the entry max_nr_stripes. However, if we have different raid type than 4/5/6, mddev->private doesn't point to struct r5conf; it may point to struct r0conf, struct r1conf, struct r10conf or struct mpconf. If we cast a pointer to one of these structs to struct r5conf, we will be reading invalid memory and KASAN warns about it. Fix this bug by reading struct r5conf only if raid type is 4, 5 or 6. CVE-2022-50084 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm raid: fix address sanitizer warning in raid_resume There is a KASAN warning in raid_resume when running the lvm test lvconvert-raid.sh. The reason for the warning is that mddev->raid_disks is greater than rs->raid_disks, so the loop touches one entry beyond the allocated length. CVE-2022-50085 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails When scpi probe fails, at any point, we need to ensure that the scpi_info is not set and will remain NULL until the probe succeeds. If it is not taken care, then it could result use-after-free as the value is exported via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc() but freed when the probe fails. CVE-2022-50087 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: locking/csd_lock: Change csdlock_debug from early_param to __setup The csdlock_debug kernel-boot parameter is parsed by the early_param() function csdlock_debug(). If set, csdlock_debug() invokes static_branch_enable() to enable csd_lock_wait feature, which triggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y and CONFIG_SPARSEMEM_VMEMMAP=n. With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called in static_key_enable() and returns NULL, resulting in a NULL dereference because mem_section is initialized only later in sparse_init(). This is also a problem for powerpc because early_param() functions are invoked earlier than jump_label_init(), also resulting in static_key_enable() failures. These failures cause the warning "static key 'xxx' used before call to jump_label_init()". Thus, early_param is too early for csd_lock_wait to run static_branch_enable(), so changes it to __setup to fix these. CVE-2022-50091 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm thin: fix use-after-free crash in dm_sm_register_threshold_callback Fault inject on pool metadata device reports: BUG: KASAN: use-after-free in dm_pool_register_metadata_threshold+0x40/0x80 Read of size 8 at addr ffff8881b9d50068 by task dmsetup/950 CPU: 7 PID: 950 Comm: dmsetup Tainted: G W 5.19.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_address_description.constprop.0.cold+0xeb/0x3f4 kasan_report.cold+0xe6/0x147 dm_pool_register_metadata_threshold+0x40/0x80 pool_ctr+0xa0a/0x1150 dm_table_add_target+0x2c8/0x640 table_load+0x1fd/0x430 ctl_ioctl+0x2c4/0x5a0 dm_ctl_ioctl+0xa/0x10 __x64_sys_ioctl+0xb3/0xd0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 This can be easily reproduced using: echo offline > /sys/block/sda/device/state dd if=/dev/zero of=/dev/mapper/thin bs=4k count=10 dmsetup load pool --table "0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0" If a metadata commit fails, the transaction will be aborted and the metadata space maps will be destroyed. If a DM table reload then happens for this failed thin-pool, a use-after-free will occur in dm_sm_register_threshold_callback (called from dm_pool_register_metadata_threshold). Fix this by in dm_pool_register_metadata_threshold() by returning the -EINVAL error if the thin-pool is in fail mode. Also fail pool_ctr() with a new error message: "Error registering metadata threshold". CVE-2022-50092 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE) KASAN reports: [ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) [ 4.676149][ T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0 [ 4.683454][ T0] [ 4.685638][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1 [ 4.694331][ T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016 [ 4.703196][ T0] Call Trace: [ 4.706334][ T0] <TASK> [ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) after converting the type of the first argument (@nr, bit number) of arch_test_bit() from `long` to `unsigned long`[0]. Under certain conditions (for example, when ACPI NUMA is disabled via command line), pxm_to_node() can return %NUMA_NO_NODE (-1). It is valid 'magic' number of NUMA node, but not valid bit number to use in bitops. node_online() eventually descends to test_bit() without checking for the input, assuming it's on caller side (which might be good for perf-critical tasks). There, -1 becomes %ULONG_MAX which leads to an insane array index when calculating bit position in memory. For now, add an explicit check for @node being not %NUMA_NO_NODE before calling test_bit(). The actual logics didn't change here at all. [0] https://github.com/norov/linux/commit/0e862838f290147ea9c16db852d8d494b552d38d CVE-2022-50093 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: spmi: trace: fix stack-out-of-bound access in SPMI tracing functions trace_spmi_write_begin() and trace_spmi_read_end() both call memcpy() with a length of "len + 1". This leads to one extra byte being read beyond the end of the specified buffer. Fix this out-of-bound memory access by using a length of "len" instead. Here is a KASAN log showing the issue: BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234 Read of size 2 at addr ffffffc0265b7540 by task thermal@2.0-ser/1314 ... Call trace: dump_backtrace+0x0/0x3e8 show_stack+0x2c/0x3c dump_stack_lvl+0xdc/0x11c print_address_description+0x74/0x384 kasan_report+0x188/0x268 kasan_check_range+0x270/0x2b0 memcpy+0x90/0xe8 trace_event_raw_event_spmi_read_end+0x1d0/0x234 spmi_read_cmd+0x294/0x3ac spmi_ext_register_readl+0x84/0x9c regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi] _regmap_raw_read+0x40c/0x754 regmap_raw_read+0x3a0/0x514 regmap_bulk_read+0x418/0x494 adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3] ... __arm64_sys_read+0x4c/0x60 invoke_syscall+0x80/0x218 el0_svc_common+0xec/0x1c8 ... addr ffffffc0265b7540 is located in stack of task thermal@2.0-ser/1314 at offset 32 in frame: adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3] this frame has 1 object: [32, 33) 'status' Memory state around the buggy address: ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 ffffffc0265b7480: 04 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffc0265b7500: 00 00 00 00 f1 f1 f1 f1 01 f3 f3 f3 00 00 00 00 ^ ffffffc0265b7580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0265b7600: f1 f1 f1 f1 01 f2 07 f2 f2 f2 01 f3 00 00 00 00 ================================================================== CVE-2022-50094 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: video: fbdev: s3fb: Check the size of screen before memset_io() In the function s3fb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug: [ 54.083733] BUG: unable to handle page fault for address: ffffc90003000000 [ 54.083742] #PF: supervisor write access in kernel mode [ 54.083744] #PF: error_code(0x0002) - not-present page [ 54.083760] RIP: 0010:memset_orig+0x33/0xb0 [ 54.083782] Call Trace: [ 54.083788] s3fb_set_par+0x1ec6/0x4040 [ 54.083806] fb_set_var+0x604/0xeb0 [ 54.083836] do_fb_ioctl+0x234/0x670 Fix the this by checking the value of 'screen_size' before memset_io(). CVE-2022-50097 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts Ensure SRB is returned during I/O timeout error escalation. If that is not possible fail the escalation path. Following crash stack was seen: BUG: unable to handle kernel paging request at 0000002f56aa90f8 IP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx] Call Trace: ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx] ? qla2x00_start_sp+0x116/0x1170 [qla2xxx] ? dma_pool_alloc+0x1d6/0x210 ? mempool_alloc+0x54/0x130 ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx] ? qla_do_work+0x2d/0x40 [qla2xxx] ? process_one_work+0x14c/0x390 CVE-2022-50098 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: video: fbdev: arkfb: Check the size of screen before memset_io() In the function arkfb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug: [ 659.399066] BUG: unable to handle page fault for address: ffffc90003000000 [ 659.399077] #PF: supervisor write access in kernel mode [ 659.399079] #PF: error_code(0x0002) - not-present page [ 659.399094] RIP: 0010:memset_orig+0x33/0xb0 [ 659.399116] Call Trace: [ 659.399122] arkfb_set_par+0x143f/0x24c0 [ 659.399130] fb_set_var+0x604/0xeb0 [ 659.399161] do_fb_ioctl+0x234/0x670 [ 659.399189] fb_ioctl+0xdd/0x130 Fix the this by checking the value of 'screen_size' before memset_io(). CVE-2022-50099 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: video: fbdev: vt8623fb: Check the size of screen before memset_io() In the function vt8623fb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug: [ 583.339036] BUG: unable to handle page fault for address: ffffc90005000000 [ 583.339049] #PF: supervisor write access in kernel mode [ 583.339052] #PF: error_code(0x0002) - not-present page [ 583.339074] RIP: 0010:memset_orig+0x33/0xb0 [ 583.339110] Call Trace: [ 583.339118] vt8623fb_set_par+0x11cd/0x21e0 [ 583.339146] fb_set_var+0x604/0xeb0 [ 583.339181] do_fb_ioctl+0x234/0x670 [ 583.339209] fb_ioctl+0xdd/0x130 Fix the this by checking the value of 'screen_size' before memset_io(). CVE-2022-50101 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: video: fbdev: arkfb: Fix a divide-by-zero bug in ark_set_pixclock() Since the user can control the arguments of the ioctl() from the user space, under special arguments that may result in a divide-by-zero bug in: drivers/video/fbdev/arkfb.c:784: ark_set_pixclock(info, (hdiv * info->var.pixclock) / hmul); with hdiv=1, pixclock=1 and hmul=2 you end up with (1*1)/2 = (int) 0. and then in: drivers/video/fbdev/arkfb.c:504: rv = dac_set_freq(par->dac, 0, 1000000000 / pixclock); we'll get a division-by-zero. The following log can reveal it: divide error: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:ark_set_pixclock drivers/video/fbdev/arkfb.c:504 [inline] RIP: 0010:arkfb_set_par+0x10fc/0x24c0 drivers/video/fbdev/arkfb.c:784 Call Trace: fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 Fix this by checking the argument of ark_set_pixclock() first. CVE-2022-50102 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: sched, cpuset: Fix dl_cpu_busy() panic due to empty cs->cpus_allowed With cgroup v2, the cpuset's cpus_allowed mask can be empty indicating that the cpuset will just use the effective CPUs of its parent. So cpuset_can_attach() can call task_can_attach() with an empty mask. This can lead to cpumask_any_and() returns nr_cpu_ids causing the call to dl_bw_of() to crash due to percpu value access of an out of bound CPU value. For example: [80468.182258] BUG: unable to handle page fault for address: ffffffff8b6648b0 : [80468.191019] RIP: 0010:dl_cpu_busy+0x30/0x2b0 : [80468.207946] Call Trace: [80468.208947] cpuset_can_attach+0xa0/0x140 [80468.209953] cgroup_migrate_execute+0x8c/0x490 [80468.210931] cgroup_update_dfl_csses+0x254/0x270 [80468.211898] cgroup_subtree_control_write+0x322/0x400 [80468.212854] kernfs_fop_write_iter+0x11c/0x1b0 [80468.213777] new_sync_write+0x11f/0x1b0 [80468.214689] vfs_write+0x1eb/0x280 [80468.215592] ksys_write+0x5f/0xe0 [80468.216463] do_syscall_64+0x5c/0x80 [80468.224287] entry_SYSCALL_64_after_hwframe+0x44/0xae Fix that by using effective_cpus instead. For cgroup v1, effective_cpus is the same as cpus_allowed. For v2, effective_cpus is the real cpumask to be used by tasks within the cpuset anyway. Also update task_can_attach()'s 2nd argument name to cs_effective_cpus to reflect the change. In addition, a check is added to task_can_attach() to guard against the possibility that cpumask_any_and() may return a value >= nr_cpu_ids. CVE-2022-50103 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: powerpc/xive: Fix refcount leak in xive_get_max_prio of_find_node_by_path() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. CVE-2022-50104 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: video: fbdev: amba-clcd: Fix refcount leak bugs In clcdfb_of_init_display(), we should call of_node_put() for the references returned by of_graph_get_next_endpoint() and of_graph_get_remote_port_parent() which have increased the refcount. Besides, we should call of_node_put() both in fail path or when the references are not used anymore. CVE-2022-50109 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix deadlock and link starvation in outgoing data path The current implementation queues up new control and user packets as needed and processes this queue down to the ldisc in the same code path. That means that the upper and the lower layer are hard coupled in the code. Due to this deadlocks can happen as seen below while transmitting data, especially during ldisc congestion. Furthermore, the data channels starve the control channel on high transmission load on the ldisc. Introduce an additional control channel data queue to prevent timeouts and link hangups during ldisc congestion. This is being processed before the user channel data queue in gsm_data_kick(), i.e. with the highest priority. Put the queue to ldisc data path into a workqueue and trigger it whenever new data has been put into the transmission queue. Change gsm_dlci_data_sweep() accordingly to fill up the transmission queue until TX_THRESH_HI. This solves the locking issue, keeps latency low and provides good performance on high data load. Note that now all packets from a DLCI are removed from the internal queue if the associated DLCI was closed. This ensures that no data is sent by the introduced write task to an already closed DLCI. BUG: spinlock recursion on CPU#0, test_v24_loop/124 lock: serial8250_ports+0x3a8/0x7500, .magic: dead4ead, .owner: test_v24_loop/124, .owner_cpu: 0 CPU: 0 PID: 124 Comm: test_v24_loop Tainted: G O 5.18.0-rc2 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x34/0x44 do_raw_spin_lock+0x76/0xa0 _raw_spin_lock_irqsave+0x72/0x80 uart_write_room+0x3b/0xc0 gsm_data_kick+0x14b/0x240 [n_gsm] gsmld_write_wakeup+0x35/0x70 [n_gsm] tty_wakeup+0x53/0x60 tty_port_default_wakeup+0x1b/0x30 serial8250_tx_chars+0x12f/0x220 serial8250_handle_irq.part.0+0xfe/0x150 serial8250_default_handle_irq+0x48/0x80 serial8250_interrupt+0x56/0xa0 __handle_irq_event_percpu+0x78/0x1f0 handle_irq_event+0x34/0x70 handle_fasteoi_irq+0x90/0x1e0 __common_interrupt+0x69/0x100 common_interrupt+0x48/0xc0 asm_common_interrupt+0x1e/0x40 RIP: 0010:__do_softirq+0x83/0x34e Code: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d e2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff <49> c7 c2 40 61 80 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00 RSP: 0018:ffffc90000003f98 EFLAGS: 00000286 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7 RBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000 ? __do_softirq+0x73/0x34e irq_exit_rcu+0xb5/0x100 common_interrupt+0xa4/0xc0 </IRQ> <TASK> asm_common_interrupt+0x1e/0x40 RIP: 0010:_raw_spin_unlock_irqrestore+0x2e/0x50 Code: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff 48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 <e8> 3d 97 33 ff 65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44 RSP: 0018:ffffc9000020fd08 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000 RDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001 RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8 ? _raw_spin_unlock_irqrestore+0x23/0x50 gsmtty_write+0x65/0x80 [n_gsm] n_tty_write+0x33f/0x530 ? swake_up_all+0xe0/0xe0 file_tty_write.constprop.0+0x1b1/0x320 ? n_tty_flush_buffer+0xb0/0xb0 new_sync_write+0x10c/0x190 vfs_write+0x282/0x310 ksys_write+0x68/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f3e5e35c15c Code: 8b 7c 24 08 89 c5 e8 c5 ff ff ff 89 ef 89 44 24 ---truncated--- CVE-2022-50116 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: jbd2: fix assertion 'jh->b_frozen_data == NULL' failure when journal aborted Following process will fail assertion 'jh->b_frozen_data == NULL' in jbd2_journal_dirty_metadata(): jbd2_journal_commit_transaction unlink(dir/a) jh->b_transaction = trans1 jh->b_jlist = BJ_Metadata journal->j_running_transaction = NULL trans1->t_state = T_COMMIT unlink(dir/b) handle->h_trans = trans2 do_get_write_access jh->b_modified = 0 jh->b_frozen_data = frozen_buffer jh->b_next_transaction = trans2 jbd2_journal_dirty_metadata is_handle_aborted is_journal_aborted // return false --> jbd2 abort <-- while (commit_transaction->t_buffers) if (is_journal_aborted) jbd2_journal_refile_buffer __jbd2_journal_refile_buffer WRITE_ONCE(jh->b_transaction, jh->b_next_transaction) WRITE_ONCE(jh->b_next_transaction, NULL) __jbd2_journal_file_buffer(jh, BJ_Reserved) J_ASSERT_JH(jh, jh->b_frozen_data == NULL) // assertion failure ! The reproducer (See detail in [Link]) reports: ------------[ cut here ]------------ kernel BUG at fs/jbd2/transaction.c:1629! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 2 PID: 584 Comm: unlink Tainted: G W 5.19.0-rc6-00115-g4a57a8400075-dirty #697 RIP: 0010:jbd2_journal_dirty_metadata+0x3c5/0x470 RSP: 0018:ffffc90000be7ce0 EFLAGS: 00010202 Call Trace: <TASK> __ext4_handle_dirty_metadata+0xa0/0x290 ext4_handle_dirty_dirblock+0x10c/0x1d0 ext4_delete_entry+0x104/0x200 __ext4_unlink+0x22b/0x360 ext4_unlink+0x275/0x390 vfs_unlink+0x20b/0x4c0 do_unlinkat+0x42f/0x4c0 __x64_sys_unlink+0x37/0x50 do_syscall_64+0x35/0x80 After journal aborting, __jbd2_journal_refile_buffer() is executed with holding @jh->b_state_lock, we can fix it by moving 'is_handle_aborted()' into the area protected by @jh->b_state_lock. CVE-2022-50126 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix error unwind in rxe_create_qp() In the function rxe_create_qp(), rxe_qp_from_init() is called to initialize qp, internally things like the spin locks are not setup until rxe_qp_init_req(). If an error occures before this point then the unwind will call rxe_cleanup() and eventually to rxe_qp_do_cleanup()/rxe_cleanup_task() which will oops when trying to access the uninitialized spinlock. Move the spinlock initializations earlier before any failures. CVE-2022-50127 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: fix potential memory leak in setup_base_ctxt() setup_base_ctxt() allocates a memory chunk for uctxt->groups with hfi1_alloc_ctxt_rcv_groups(). When init_user_ctxt() fails, uctxt->groups is not released, which will lead to a memory leak. We should release the uctxt->groups with hfi1_free_ctxt_rcv_groups() when init_user_ctxt() fails. CVE-2022-50134 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/qedr: Fix potential memory leak in __qedr_alloc_mr() __qedr_alloc_mr() allocates a memory chunk for "mr->info.pbl_table" with init_mr_info(). When rdma_alloc_tid() and rdma_register_tid() fail, "mr" is released while "mr->info.pbl_table" is not released, which will lead to a memory leak. We should release the "mr->info.pbl_table" with qedr_free_pbl() when error occurs to fix the memory leak. CVE-2022-50138 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-of-esdhc: Fix refcount leak in esdhc_signal_voltage_switch of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() checks null pointer. CVE-2022-50141 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: PCI: dwc: Deallocate EPC memory on dw_pcie_ep_init() errors If dw_pcie_ep_init() fails to perform any action after the EPC memory is initialized and the MSI memory region is allocated, the latter parts won't be undone thus causing a memory leak. Add a cleanup-on-error path to fix these leaks. [bhelgaas: commit log] CVE-2022-50146 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: driver core: fix potential deadlock in __driver_attach In __driver_attach function, There are also AA deadlock problem, like the commit b232b02bf3c2 ("driver core: fix deadlock in __device_attach"). stack like commit b232b02bf3c2 ("driver core: fix deadlock in __device_attach"). list below: In __driver_attach function, The lock holding logic is as follows: ... __driver_attach if (driver_allows_async_probing(drv)) device_lock(dev) // get lock dev async_schedule_dev(__driver_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* when fail or work limit, sync to execute func, but __driver_attach_async_helper will get lock dev as will, which will lead to A-A deadlock. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev) As above show, when it is allowed to do async probes, because of out of memory or work limit, async work is not be allowed, to do sync execute instead. it will lead to A-A deadlock because of __driver_attach_async_helper getting lock dev. Reproduce: and it can be reproduce by make the condition (if (!entry || atomic_read(&entry_count) > MAX_WORK)) untenable, like below: [ 370.785650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 370.787154] task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00004000 [ 370.788865] Call Trace: [ 370.789374] <TASK> [ 370.789841] __schedule+0x482/0x1050 [ 370.790613] schedule+0x92/0x1a0 [ 370.791290] schedule_preempt_disabled+0x2c/0x50 [ 370.792256] __mutex_lock.isra.0+0x757/0xec0 [ 370.793158] __mutex_lock_slowpath+0x1f/0x30 [ 370.794079] mutex_lock+0x50/0x60 [ 370.794795] __device_driver_lock+0x2f/0x70 [ 370.795677] ? driver_probe_device+0xd0/0xd0 [ 370.796576] __driver_attach_async_helper+0x1d/0xd0 [ 370.797318] ? driver_probe_device+0xd0/0xd0 [ 370.797957] async_schedule_node_domain+0xa5/0xc0 [ 370.798652] async_schedule_node+0x19/0x30 [ 370.799243] __driver_attach+0x246/0x290 [ 370.799828] ? driver_allows_async_probing+0xa0/0xa0 [ 370.800548] bus_for_each_dev+0x9d/0x130 [ 370.801132] driver_attach+0x22/0x30 [ 370.801666] bus_add_driver+0x290/0x340 [ 370.802246] driver_register+0x88/0x140 [ 370.802817] ? virtio_scsi_init+0x116/0x116 [ 370.803425] scsi_register_driver+0x1a/0x30 [ 370.804057] init_sd+0x184/0x226 [ 370.804533] do_one_initcall+0x71/0x3a0 [ 370.805107] kernel_init_freeable+0x39a/0x43a [ 370.805759] ? rest_init+0x150/0x150 [ 370.806283] kernel_init+0x26/0x230 [ 370.806799] ret_from_fork+0x1f/0x30 To fix the deadlock, move the async_schedule_dev outside device_lock, as we can see, in async_schedule_node_domain, the parameter of queue_work_node is system_unbound_wq, so it can accept concurrent operations. which will also not change the code logic, and will not lead to deadlock. CVE-2022-50149 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: ohci-nxp: Fix refcount leak in ohci_hcd_nxp_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. CVE-2022-50152 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: host: Fix refcount leak in ehci_hcd_ppc_of_probe of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. CVE-2022-50153 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: of: check previous kernel's ima-kexec-buffer against memory bounds Presently ima_get_kexec_buffer() doesn't check if the previous kernel's ima-kexec-buffer lies outside the addressable memory range. This can result in a kernel panic if the new kernel is booted with 'mem=X' arg and the ima-kexec-buffer was allocated beyond that range by the previous kernel. The panic is usually of the form below: $ sudo kexec --initrd initrd vmlinux --append='mem=16G' <snip> BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000 Faulting instruction address: 0xc000000000837974 Oops: Kernel access of bad area, sig: 11 [#1] <snip> NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0 LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 Call Trace: [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108 [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120 [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0 [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0 [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330 7c0802a6 fb610198 7c9b2378 f80101d0 <a1240000> 2c090001 40820614 e9240010 ---[ end trace 0000000000000000 ]--- Fix this issue by checking returned PFN range of previous kernel's ima-kexec-buffer with page_is_ram() to ensure correct memory bounds. CVE-2022-50159 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: Fix possible refcount leak in if_usb_probe() usb_get_dev will be called before lbs_get_firmware_async which means that usb_put_dev need to be called when lbs_get_firmware_async fails. CVE-2022-50162 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Fix global state lock backoff We need to grab the lock after the early return for !hwpipe case. Otherwise, we could have hit contention yet still returned 0. Fixes an issue that the new CONFIG_DRM_DEBUG_MODESET_LOCK stuff flagged in CI: WARNING: CPU: 0 PID: 282 at drivers/gpu/drm/drm_modeset_lock.c:296 drm_modeset_lock+0xf8/0x154 Modules linked in: CPU: 0 PID: 282 Comm: kms_cursor_lega Tainted: G W 5.19.0-rc2-15930-g875cc8bc536a #1 Hardware name: Qualcomm Technologies, Inc. DB820c (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_modeset_lock+0xf8/0x154 lr : drm_atomic_get_private_obj_state+0x84/0x170 sp : ffff80000cfab6a0 x29: ffff80000cfab6a0 x28: 0000000000000000 x27: ffff000083bc4d00 x26: 0000000000000038 x25: 0000000000000000 x24: ffff80000957ca58 x23: 0000000000000000 x22: ffff000081ace080 x21: 0000000000000001 x20: ffff000081acec18 x19: ffff80000cfabb80 x18: 0000000000000038 x17: 0000000000000000 x16: 0000000000000000 x15: fffffffffffea0d0 x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 5f534b434f4c5f47 x11: ffff80000a386aa8 x10: 0000000000000029 x9 : ffff80000cfab610 x8 : 0000000000000029 x7 : 0000000000000014 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff8000081ad904 x3 : 0000000000000029 x2 : ffff0000801db4c0 x1 : ffff80000cfabb80 x0 : ffff000081aceb58 Call trace: drm_modeset_lock+0xf8/0x154 drm_atomic_get_private_obj_state+0x84/0x170 mdp5_get_global_state+0x54/0x6c mdp5_pipe_release+0x2c/0xd4 mdp5_plane_atomic_check+0x2ec/0x414 drm_atomic_helper_check_planes+0xd8/0x210 drm_atomic_helper_check+0x54/0xb0 ... ---[ end trace 0000000000000000 ]--- drm_modeset_lock attempting to lock a contended lock without backoff: drm_modeset_lock+0x148/0x154 mdp5_get_global_state+0x30/0x6c mdp5_pipe_release+0x2c/0xd4 mdp5_plane_atomic_check+0x290/0x414 drm_atomic_helper_check_planes+0xd8/0x210 drm_atomic_helper_check+0x54/0xb0 drm_atomic_check_only+0x4b0/0x8f4 drm_atomic_commit+0x68/0xe0 Patchwork: https://patchwork.freedesktop.org/patch/492701/ CVE-2022-50173 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: virtio-gpu: fix a missing check to avoid NULL dereference 'cache_ent' could be set NULL inside virtio_gpu_cmd_get_capset() and it will lead to a NULL dereference by a lately use of it (i.e., ptr = cache_ent->caps_cache). Fix it with a NULL check. [ kraxel: minor codestyle fixup ] CVE-2022-50181 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix potential buffer overflow in ni_set_mc_special_registers() The last case label can write two buffers 'mc_reg_address[j]' and 'mc_data[j]' with 'j' offset equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE since there are no checks for this value in both case labels after the last 'j++'. Instead of changing '>' to '>=' there, add the bounds check at the start of the second 'case' (the first one already has it). Also, remove redundant last checks for 'j' index bigger than array size. The expression is always false. Moreover, before or after the patch 'table->last' can be equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE and it seems it can be a valid value. Detected using the static analysis tool - Svace. CVE-2022-50185 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: regulator: of: Fix refcount leak bug in of_get_regulation_constraints() We should call the of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount. CVE-2022-50191 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: selinux: Add boundary check in put_entry() Just like next_entry(), boundary check is necessary to prevent memory out-of-bound access. CVE-2022-50200 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: arm64: fix oops in concurrently setting insn_emulation sysctls emulation_proc_handler() changes table->data for proc_dointvec_minmax and can generate the following Oops if called concurrently with itself: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 | Internal error: Oops: 96000006 [#1] SMP | Call trace: | update_insn_emulation_mode+0xc0/0x148 | emulation_proc_handler+0x64/0xb8 | proc_sys_call_handler+0x9c/0xf8 | proc_sys_write+0x18/0x20 | __vfs_write+0x20/0x48 | vfs_write+0xe4/0x1d0 | ksys_write+0x70/0xf8 | __arm64_sys_write+0x20/0x28 | el0_svc_common.constprop.0+0x7c/0x1c0 | el0_svc_handler+0x2c/0xa0 | el0_svc+0x8/0x200 To fix this issue, keep the table->data as &insn->current_mode and use container_of() to retrieve the insn pointer. Another mutex is used to protect against the current_mode update but not for retrieving insn_emulation as table->data is no longer changing. CVE-2022-50206 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: md-raid10: fix KASAN warning There's a KASAN warning in raid10_remove_disk when running the lvm test lvconvert-raid-reshape.sh. We fix this warning by verifying that the value "number" is valid. BUG: KASAN: slab-out-of-bounds in raid10_remove_disk+0x61/0x2a0 [raid10] Read of size 8 at addr ffff889108f3d300 by task mdX_raid10/124682 CPU: 3 PID: 124682 Comm: mdX_raid10 Not tainted 5.19.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_report.cold+0x45/0x57a ? __lock_text_start+0x18/0x18 ? raid10_remove_disk+0x61/0x2a0 [raid10] kasan_report+0xa8/0xe0 ? raid10_remove_disk+0x61/0x2a0 [raid10] raid10_remove_disk+0x61/0x2a0 [raid10] Buffer I/O error on dev dm-76, logical block 15344, async page read ? __mutex_unlock_slowpath.constprop.0+0x1e0/0x1e0 remove_and_add_spares+0x367/0x8a0 [md_mod] ? super_written+0x1c0/0x1c0 [md_mod] ? mutex_trylock+0xac/0x120 ? _raw_spin_lock+0x72/0xc0 ? _raw_spin_lock_bh+0xc0/0xc0 md_check_recovery+0x848/0x960 [md_mod] raid10d+0xcf/0x3360 [raid10] ? sched_clock_cpu+0x185/0x1a0 ? rb_erase+0x4d4/0x620 ? var_wake_function+0xe0/0xe0 ? psi_group_change+0x411/0x500 ? preempt_count_sub+0xf/0xc0 ? _raw_spin_lock_irqsave+0x78/0xc0 ? __lock_text_start+0x18/0x18 ? raid10_sync_request+0x36c0/0x36c0 [raid10] ? preempt_count_sub+0xf/0xc0 ? _raw_spin_unlock_irqrestore+0x19/0x40 ? del_timer_sync+0xa9/0x100 ? try_to_del_timer_sync+0xc0/0xc0 ? _raw_spin_lock_irqsave+0x78/0xc0 ? __lock_text_start+0x18/0x18 ? _raw_spin_unlock_irq+0x11/0x24 ? __list_del_entry_valid+0x68/0xa0 ? finish_wait+0xa3/0x100 md_thread+0x161/0x260 [md_mod] ? unregister_md_personality+0xa0/0xa0 [md_mod] ? _raw_spin_lock_irqsave+0x78/0xc0 ? prepare_to_wait_event+0x2c0/0x2c0 ? unregister_md_personality+0xa0/0xa0 [md_mod] kthread+0x148/0x180 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Allocated by task 124495: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x80/0xa0 setup_conf+0x140/0x5c0 [raid10] raid10_run+0x4cd/0x740 [raid10] md_run+0x6f9/0x1300 [md_mod] raid_ctr+0x2531/0x4ac0 [dm_raid] dm_table_add_target+0x2b0/0x620 [dm_mod] table_load+0x1c8/0x400 [dm_mod] ctl_ioctl+0x29e/0x560 [dm_mod] dm_compat_ctl_ioctl+0x7/0x20 [dm_mod] __do_compat_sys_ioctl+0xfa/0x160 do_syscall_64+0x90/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x9e/0xc0 kvfree_call_rcu+0x84/0x480 timerfd_release+0x82/0x140 L __fput+0xfa/0x400 task_work_run+0x80/0xc0 exit_to_user_mode_prepare+0x155/0x160 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x42/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Second to last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x9e/0xc0 kvfree_call_rcu+0x84/0x480 timerfd_release+0x82/0x140 __fput+0xfa/0x400 task_work_run+0x80/0xc0 exit_to_user_mode_prepare+0x155/0x160 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x42/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The buggy address belongs to the object at ffff889108f3d200 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes to the right of 256-byte region [ffff889108f3d200, ffff889108f3d300) The buggy address belongs to the physical page: page:000000007ef2a34c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1108f3c head:000000007ef2a34c order:2 compound_mapcount:0 compound_pincount:0 flags: 0x4000000000010200(slab|head|zone=2) raw: 4000000000010200 0000000000000000 dead000000000001 ffff889100042b40 raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff889108f3d200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff889108f3d280: 00 00 ---truncated--- CVE-2022-50211 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Allow waiting for commands to complete on removed device When a SCSI device is removed while in active use, currently sg will immediately return -ENODEV on any attempt to wait for active commands that were sent before the removal. This is problematic for commands that use SG_FLAG_DIRECT_IO since the data buffer may still be in use by the kernel when userspace frees or reuses it after getting ENODEV, leading to corrupted userspace memory (in the case of READ-type commands) or corrupted data being sent to the device (in the case of WRITE-type commands). This has been seen in practice when logging out of a iscsi_tcp session, where the iSCSI driver may still be processing commands after the device has been marked for removal. Change the policy to allow userspace to wait for active sg commands even when the device is being removed. Return -ENODEV only when there are no more responses to read. CVE-2022-50215 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: usbnet: Fix linkwatch use-after-free on disconnect usbnet uses the work usbnet_deferred_kevent() to perform tasks which may sleep. On disconnect, completion of the work was originally awaited in ->ndo_stop(). But in 2003, that was moved to ->disconnect() by historic commit "[PATCH] USB: usbnet, prevent exotic rtnl deadlock": https://git.kernel.org/tglx/history/c/0f138bbfd83c The change was made because back then, the kernel's workqueue implementation did not allow waiting for a single work. One had to wait for completion of *all* work by calling flush_scheduled_work(), and that could deadlock when waiting for usbnet_deferred_kevent() with rtnl_mutex held in ->ndo_stop(). The commit solved one problem but created another: It causes a use-after-free in USB Ethernet drivers aqc111.c, asix_devices.c, ax88179_178a.c, ch9200.c and smsc75xx.c: * If the drivers receive a link change interrupt immediately before disconnect, they raise EVENT_LINK_RESET in their (non-sleepable) ->status() callback and schedule usbnet_deferred_kevent(). * usbnet_deferred_kevent() invokes the driver's ->link_reset() callback, which calls netif_carrier_{on,off}(). * That in turn schedules the work linkwatch_event(). Because usbnet_deferred_kevent() is awaited after unregister_netdev(), netif_carrier_{on,off}() may operate on an unregistered netdev and linkwatch_event() may run after free_netdev(), causing a use-after-free. In 2010, usbnet was changed to only wait for a single instance of usbnet_deferred_kevent() instead of *all* work by commit 23f333a2bfaf ("drivers/net: don't use flush_scheduled_work()"). Unfortunately the commit neglected to move the wait back to ->ndo_stop(). Rectify that omission at long last. CVE-2022-50220 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Use kzalloc for sev ioctl interfaces to prevent kernel memory leak For some sev ioctl interfaces, input may be passed that is less than or equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data that PSP firmware returns. In this case, kmalloc will allocate memory that is the size of the input rather than the size of the data. Since PSP firmware doesn't fully overwrite the buffer, the sev ioctl interfaces with the issue may return uninitialized slab memory. Currently, all of the ioctl interfaces in the ccp driver are safe, but to prevent future problems, change all ioctl interfaces that allocate memory with kmalloc to use kzalloc and memset the data buffer to zero in sev_ioctl_do_platform_status. CVE-2022-50226 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0 Don't BUG/WARN on interrupt injection due to GIF being cleared, since it's trivial for userspace to force the situation via KVM_SET_VCPU_EVENTS (even if having at least a WARN there would be correct for KVM internally generated injections). kernel BUG at arch/x86/kvm/svm/svm.c:3386! invalid opcode: 0000 [#1] SMP CPU: 15 PID: 926 Comm: smm_test Not tainted 5.17.0-rc3+ #264 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_inject_irq+0xab/0xb0 [kvm_amd] Code: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53 RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006 RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0 RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000 FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0 Call Trace: <TASK> inject_pending_event+0x2f7/0x4c0 [kvm] kvm_arch_vcpu_ioctl_run+0x791/0x17a0 [kvm] kvm_vcpu_ioctl+0x26d/0x650 [kvm] __x64_sys_ioctl+0x82/0xb0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> CVE-2022-50228 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: bcd2000: Fix a UAF bug on the error path of probing When the driver fails in snd_card_register() at probe time, it will free the 'bcd2k->midi_out_urb' before killing it, which may cause a UAF bug. The following log can reveal it: [ 50.727020] BUG: KASAN: use-after-free in bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000] [ 50.727623] Read of size 8 at addr ffff88810fab0e88 by task swapper/4/0 [ 50.729530] Call Trace: [ 50.732899] bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000] Fix this by adding usb_kill_urb() before usb_free_urb(). CVE-2022-50229 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate A use-after-free flaw was found in btsdio_remove in drivers\bluetooth\btsdio.c in the Linux Kernel. In this flaw, a call to btsdio_remove with an unfinished job, may cause a race problem leading to a UAF on hdev devices. CVE-2023-1989 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important A vulnerability was found in compare_netdev_and_ip in drivers/infiniband/core/cma.c in RDMA in the Linux Kernel. The improper cleanup results in out-of-boundary read, where a local user can utilize this problem to crash the system or escalation of privilege. CVE-2023-2176 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important A use after free vulnerability was found in prepare_to_relocate in fs/btrfs/relocation.c in btrfs in the Linux Kernel. This possible flaw can be triggered by calling btrfs_ioctl_balance() before calling btrfs_ioctl_defrag(). CVE-2023-3111 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command Tags allocated for OPC_INB_SET_CONTROLLER_CONFIG command need to be freed when we receive the response. CVE-2023-52500 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix hungtask for PADATA_RESET We found a hungtask bug in test_aead_vec_cfg as follows: INFO: task cryptomgr_test:391009 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Call trace: __switch_to+0x98/0xe0 __schedule+0x6c4/0xf40 schedule+0xd8/0x1b4 schedule_timeout+0x474/0x560 wait_for_common+0x368/0x4e0 wait_for_completion+0x20/0x30 wait_for_completion+0x20/0x30 test_aead_vec_cfg+0xab4/0xd50 test_aead+0x144/0x1f0 alg_test_aead+0xd8/0x1e0 alg_test+0x634/0x890 cryptomgr_test+0x40/0x70 kthread+0x1e0/0x220 ret_from_fork+0x10/0x18 Kernel panic - not syncing: hung_task: blocked tasks For padata_do_parallel, when the return err is 0 or -EBUSY, it will call wait_for_completion(&wait->completion) in test_aead_vec_cfg. In normal case, aead_request_complete() will be called in pcrypt_aead_serial and the return err is 0 for padata_do_parallel. But, when pinst->flags is PADATA_RESET, the return err is -EBUSY for padata_do_parallel, and it won't call aead_request_complete(). Therefore, test_aead_vec_cfg will hung at wait_for_completion(&wait->completion), which will cause hungtask. The problem comes as following: (padata_do_parallel) | rcu_read_lock_bh(); | err = -EINVAL; | (padata_replace) | pinst->flags |= PADATA_RESET; err = -EBUSY | if (pinst->flags & PADATA_RESET) | rcu_read_unlock_bh() | return err In order to resolve the problem, we replace the return err -EBUSY with -EAGAIN, which means parallel_data is changing, and the caller should call it again. v3: remove retry and just change the return err. v2: introduce padata_try_do_parallel() in pcrypt_aead_encrypt and pcrypt_aead_decrypt to solve the hungtask. CVE-2023-52813 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds If the "struct can_priv::echoo_skb" is accessed out of bounds, this would cause a kernel crash. Instead, issue a meaningful warning message and return with an error. CVE-2023-52878 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: allow exp not to be removed in nf_ct_find_expectation Currently nf_conntrack_in() calling nf_ct_find_expectation() will remove the exp from the hash table. However, in some scenario, we expect the exp not to be removed when the created ct will not be confirmed, like in OVS and TC conntrack in the following patches. This patch allows exp not to be removed by setting IPS_CONFIRMED in the status of the tmpl. CVE-2023-52927 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: l2tp: close all race conditions in l2tp_tunnel_register() The code in l2tp_tunnel_register() is racy in several ways: 1. It modifies the tunnel socket _after_ publishing it. 2. It calls setup_udp_tunnel_sock() on an existing socket without locking. 3. It changes sock lock class on fly, which triggers many syzbot reports. This patch amends all of them by moving socket initialization code before publishing and under sock lock. As suggested by Jakub, the l2tp lockdep class is not necessary as we can just switch to bh_lock_sock_nested(). CVE-2023-53020 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2023-53063 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix data corruption after failed write When buffered write fails to copy data into underlying page cache page, ocfs2_write_end_nolock() just zeroes out and dirties the page. This can leave dirty page beyond EOF and if page writeback tries to write this page before write succeeds and expands i_size, page gets into inconsistent state where page dirty bit is clear but buffer dirty bits stay set resulting in page data never getting written and so data copied to the page is lost. Fix the problem by invalidating page beyond EOF after failed write. CVE-2023-53081 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix an illegal memory access In the kfd_wait_on_events() function, the kfd_event_waiter structure is allocated by alloc_event_waiters(), but the event field of the waiter structure is not initialized; When copy_from_user() fails in the kfd_wait_on_events() function, it will enter exception handling to release the previously allocated memory of the waiter structure; Due to the event field of the waiters structure being accessed in the free_waiters() function, this results in illegal memory access and system crash, here is the crash log: localhost kernel: RIP: 0010:native_queued_spin_lock_slowpath+0x185/0x1e0 localhost kernel: RSP: 0018:ffffaa53c362bd60 EFLAGS: 00010082 localhost kernel: RAX: ff3d3d6bff4007cb RBX: 0000000000000282 RCX: 00000000002c0000 localhost kernel: RDX: ffff9e855eeacb80 RSI: 000000000000279c RDI: ffffe7088f6a21d0 localhost kernel: RBP: ffffe7088f6a21d0 R08: 00000000002c0000 R09: ffffaa53c362be64 localhost kernel: R10: ffffaa53c362bbd8 R11: 0000000000000001 R12: 0000000000000002 localhost kernel: R13: ffff9e7ead15d600 R14: 0000000000000000 R15: ffff9e7ead15d698 localhost kernel: FS: 0000152a3d111700(0000) GS:ffff9e855ee80000(0000) knlGS:0000000000000000 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 localhost kernel: CR2: 0000152938000010 CR3: 000000044d7a4000 CR4: 00000000003506e0 localhost kernel: Call Trace: localhost kernel: _raw_spin_lock_irqsave+0x30/0x40 localhost kernel: remove_wait_queue+0x12/0x50 localhost kernel: kfd_wait_on_events+0x1b6/0x490 [hydcu] localhost kernel: ? ftrace_graph_caller+0xa0/0xa0 localhost kernel: kfd_ioctl+0x38c/0x4a0 [hydcu] localhost kernel: ? kfd_ioctl_set_trap_handler+0x70/0x70 [hydcu] localhost kernel: ? kfd_ioctl_create_queue+0x5a0/0x5a0 [hydcu] localhost kernel: ? ftrace_graph_caller+0xa0/0xa0 localhost kernel: __x64_sys_ioctl+0x8e/0xd0 localhost kernel: ? syscall_trace_enter.isra.18+0x143/0x1b0 localhost kernel: do_syscall_64+0x33/0x80 localhost kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 localhost kernel: RIP: 0033:0x152a4dff68d7 Allocate the structure with kcalloc, and remove redundant 0-initialization and a redundant loop condition check. CVE-2023-53090 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: update s_journal_inum if it changes after journal replay When mounting a crafted ext4 image, s_journal_inum may change after journal replay, which is obviously unreasonable because we have successfully loaded and replayed the journal through the old s_journal_inum. And the new s_journal_inum bypasses some of the checks in ext4_get_journal(), which may trigger a null pointer dereference problem. So if s_journal_inum changes after the journal replay, we ignore the change, and rewrite the current journal_inum to the superblock. CVE-2023-53091 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: fs: prevent out-of-bounds array speculation when closing a file descriptor Google-Bug-Id: 114199369 CVE-2023-53117 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix a procfs host directory removal regression scsi_proc_hostdir_rm() decreases a reference counter and hence must only be called once per host that is removed. This change does not require a scsi_add_host_with_dma() change since scsi_add_host_with_dma() will return 0 (success) if scsi_proc_host_add() is called. CVE-2023-53118 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser() When the buffer length of the recvmsg system call is 0, we got the flollowing soft lockup problem: watchdog: BUG: soft lockup - CPU#3 stuck for 27s! [a.out:6149] CPU: 3 PID: 6149 Comm: a.out Kdump: loaded Not tainted 6.2.0+ #30 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:remove_wait_queue+0xb/0xc0 Code: 5e 41 5f c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 57 <41> 56 41 55 41 54 55 48 89 fd 53 48 89 f3 4c 8d 6b 18 4c 8d 73 20 RSP: 0018:ffff88811b5978b8 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff88811a7d3780 RCX: ffffffffb7a4d768 RDX: dffffc0000000000 RSI: ffff88811b597908 RDI: ffff888115408040 RBP: 1ffff110236b2f1b R08: 0000000000000000 R09: ffff88811a7d37e7 R10: ffffed10234fa6fc R11: 0000000000000001 R12: ffff88811179b800 R13: 0000000000000001 R14: ffff88811a7d38a8 R15: ffff88811a7d37e0 FS: 00007f6fb5398740(0000) GS:ffff888237180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000000 CR3: 000000010b6ba002 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tcp_msg_wait_data+0x279/0x2f0 tcp_bpf_recvmsg_parser+0x3c6/0x490 inet_recvmsg+0x280/0x290 sock_recvmsg+0xfc/0x120 ____sys_recvmsg+0x160/0x3d0 ___sys_recvmsg+0xf0/0x180 __sys_recvmsg+0xea/0x1a0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc The logic in tcp_bpf_recvmsg_parser is as follows: msg_bytes_ready: copied = sk_msg_recvmsg(sk, psock, msg, len, flags); if (!copied) { wait data; goto msg_bytes_ready; } In this case, "copied" always is 0, the infinite loop occurs. According to the Linux system call man page, 0 should be returned in this case. Therefore, in tcp_bpf_recvmsg_parser(), if the length is 0, directly return. Also modify several other functions with the same problem. CVE-2023-53133 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate A vulnerability was found in PAM. The secret information is stored in memory, where the attacker can trigger the victim program to execute by sending characters to its standard input (stdin). As this occurs, the attacker can train the branch predictor to execute an ROP chain speculatively. This flaw could result in leaked passwords, such as those found in /etc/shadow while performing authentications. CVE-2024-10041 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:pam-1.1.8-24.77.1 moderate The urllib.parse.urlsplit() and urlparse() functions improperly validated bracketed hosts (`[]`), allowing hosts that weren't IPv6 or IPvFuture. This behavior was not conformant to RFC 3986 and potentially enabled SSRF if a URL is processed by more than one URL parser. CVE-2024-11168 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libpython3_4m1_0-3.4.10-25.158.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:python3-base-3.4.10-25.158.1 low Allows modifying some file metadata (e.g. last modified) with filter="data" or file permissions (chmod) with filter="tar" of files outside the extraction directory. You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of "data" or "tar". See the tarfile extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter for more information. Only Python versions 3.12 or later are affected by these vulnerabilities, earlier versions don't include the extraction filter feature. Note that for Python 3.14 or later the default value of filter= changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected. Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links. CVE-2024-12718 moderate A timing-based side-channel flaw was found in libgcrypt's RSA implementation. This issue may allow a remote attacker to initiate a Bleichenbacher-style attack, which can lead to the decryption of RSA ciphertexts. CVE-2024-2236 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libgcrypt20-1.6.1-16.86.1 moderate In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix stack corruption When tc filters are first added to a net device, the corresponding local port gets bound to an ACL group in the device. The group contains a list of ACLs. In turn, each ACL points to a different TCAM region where the filters are stored. During forwarding, the ACLs are sequentially evaluated until a match is found. One reason to place filters in different regions is when they are added with decreasing priorities and in an alternating order so that two consecutive filters can never fit in the same region because of their key usage. In Spectrum-2 and newer ASICs the firmware started to report that the maximum number of ACLs in a group is more than 16, but the layout of the register that configures ACL groups (PAGT) was not updated to account for that. It is therefore possible to hit stack corruption [1] in the rare case where more than 16 ACLs in a group are required. Fix by limiting the maximum ACL group size to the minimum between what the firmware reports and the maximum ACLs that fit in the PAGT register. Add a test case to make sure the machine does not crash when this condition is hit. [1] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b CVE-2024-26586 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfc: nci: free rx_data_reassembly skb on NCI device cleanup rx_data_reassembly skb is stored during NCI data exchange for processing fragmented packets. It is dropped only when the last fragment is processed or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received. However, the NCI device may be deallocated before that which leads to skb leak. As by design the rx_data_reassembly skb is bound to the NCI device and nothing prevents the device to be freed before the skb is processed in some way and cleaned, free it on the NCI device cleanup. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. CVE-2024-26825 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Do not register event handler until srpt device is fully setup Upon rare occasions, KASAN reports a use-after-free Write in srpt_refresh_port(). This seems to be because an event handler is registered before the srpt device is fully setup and a race condition upon error may leave a partially setup event handler in place. Instead, only register the event handler after srpt device initialization is complete. CVE-2024-26872 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix uaf in pvr2_context_set_notify [Syzbot reported] BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26 CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272 Freed by task 906: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inline] slab_free mm/slub.c:4299 [inline] kfree+0x105/0x340 mm/slub.c:4409 pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline] pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158 [Analyze] Task A set disconnect_flag = !0, which resulted in Task B's condition being met and releasing mp, leading to this issue. [Fix] Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect() to avoid this issue. CVE-2024-26875 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: crypto: qat - resolve race condition during AER recovery During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the reset_data structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the reset_data structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug. This results in a KFENCE bug notice. BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340 To resolve this race condition, the memory associated to the container of the work_struct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completion_done() function. CVE-2024-26974 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: Squashfs: check the inode number is not the invalid value of zero Syskiller has produced an out of bounds access in fill_meta_index(). That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked. The reason this causes the out of bounds access is due to following sequence of events: 1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number). 2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed. This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is. [phillip@squashfs.org.uk: whitespace fix] CVE-2024-26982 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access. CVE-2024-28956 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group The DisplayPort driver's sysfs nodes may be present to the userspace before typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in hpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returns NULL in those cases. Remove manual sysfs node creation in favor of adding attribute group as default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is not used here otherwise the path to the sysfs nodes is no longer compliant with the ABI. CVE-2024-35790 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: replace physindev with physinif in nf_bridge_info An skb can be added to a neigh->arp_queue while waiting for an arp reply. Where original skb's skb->dev can be different to neigh's neigh->dev. For instance in case of bridging dnated skb from one veth to another, the skb would be added to a neigh->arp_queue of the bridge. As skb->dev can be reset back to nf_bridge->physindev and used, and as there is no explicit mechanism that prevents this physindev from been freed under us (for instance neigh_flush_dev doesn't cleanup skbs from different device's neigh queue) we can crash on e.g. this stack: arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finish Let's use plain ifindex instead of net_device link. To peek into the original net_device we will use dev_get_by_index_rcu(). Thus either we get device and are safe to use it or we don't get it and drop skb. CVE-2024-35839 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map() If we fail to allocate propname buffer, we need to drop the reference count we just took. Because the pinctrl_dt_free_maps() includes the droping operation, here we call it directly. CVE-2024-36959 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix possible use-after-free issue in ftrace_location() KASAN reports a bug: BUG: KASAN: use-after-free in ftrace_location+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 print_report+0xcf/0x610 kasan_report+0xb5/0xe0 ftrace_location+0x90/0x120 register_kprobe+0x14b/0xa40 kprobe_init+0x2d/0xff0 [kprobe_example] do_one_initcall+0x8f/0x2d0 do_init_module+0x13a/0x3c0 load_module+0x3082/0x33d0 init_module_from_file+0xd2/0x130 __x64_sys_finit_module+0x306/0x440 do_syscall_64+0x68/0x140 entry_SYSCALL_64_after_hwframe+0x71/0x79 The root cause is that, in lookup_rec(), ftrace record of some address is being searched in ftrace pages of some module, but those ftrace pages at the same time is being freed in ftrace_release_mod() as the corresponding module is being deleted: CPU1 | CPU2 register_kprobes() { | delete_module() { check_kprobe_address_safe() { | arch_check_ftrace_location() { | ftrace_location() { | lookup_rec() // USE! | ftrace_release_mod() // Free! To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftrace_location_range(); 2. Use ftrace_location_range() instead of lookup_rec() in ftrace_location(); 3. Call synchronize_rcu() before freeing any ftrace pages both in ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem(). CVE-2024-38588 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: do not BUG_ON() when freeing tree block after error When freeing a tree block, at btrfs_free_tree_block(), if we fail to create a delayed reference we don't deal with the error and just do a BUG_ON(). The error most likely to happen is -ENOMEM, and we have a comment mentioning that only -ENOMEM can happen, but that is not true, because in case qgroups are enabled any error returned from btrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returned from btrfs_search_slot() for example) can be propagated back to btrfs_free_tree_block(). So stop doing a BUG_ON() and return the error to the callers and make them abort the transaction to prevent leaking space. Syzbot was triggering this, likely due to memory allocation failure injection. CVE-2024-44963 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: perf/aux: Fix AUX buffer serialization Ole reported that event->mmap_mutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it. Note that in the lock order comment the perf_event::mmap_mutex order was already wrong, that is, it nesting under mmap_lock is not new with this patch. CVE-2024-46713 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via *<ptr> = val. The .arg*_size has been initialized reflecting the actual sizeof(*<ptr>). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write *<ptr> = val. CVE-2024-49861 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate A flaw was found in Avahi-daemon, which relies on fixed source ports for wide-area DNS queries. This issue simplifies attacks where malicious DNS responses are injected. CVE-2024-52615 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libavahi-client3-0.6.32-32.33.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libavahi-common3-0.6.32-32.33.1 moderate GNU GRUB (aka GRUB2) through 2.12 does not use a constant-time algorithm for grub_crypto_memcmp and thus allows side-channel attacks. CVE-2024-56738 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:grub2-2.02-190.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:grub2-i386-pc-2.02-190.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:grub2-x86_64-efi-2.02-190.1 moderate In the Linux kernel, the following vulnerability has been resolved: xfrm: state: fix out-of-bounds read during lookup lookup and resize can run in parallel. The xfrm_state_hash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array. rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask; While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) { This is only safe in case the update to state_bydst is larger than net->xfrm.xfrm_state_hmask (or if the lookup function gets serialized via state spinlock again). Fix this by prefetching state_hmask and the associated pointers. The xfrm_state_hash_generation seqlock retry will ensure that the pointer and the hmask will be consistent. The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side. xfrm_state_lookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch. CVE-2024-57982 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate curl's websocket code did not update the 32 bit mask pattern for each new outgoing frame as the specification says. Instead it used a fixed mask that persisted and was used throughout the entire connection. A predictable mask pattern allows for a malicious server to induce traffic between the two communicating parties that could be interpreted by an involved proxy (configured or transparent) as genuine, real, HTTP traffic with content and thereby poison its cache. That cached poisoned content could then be served to all users of that proxy. CVE-2025-10148 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:curl-8.0.1-11.108.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libcurl4-8.0.1-11.108.1 moderate In the Linux kernel, the following vulnerability has been resolved: nbd: don't allow reconnect after disconnect Following process can cause nbd_config UAF: 1) grab nbd_config temporarily; 2) nbd_genl_disconnect() flush all recv_work() and release the initial reference: nbd_genl_disconnect nbd_disconnect_and_put nbd_disconnect flush_workqueue(nbd->recv_workq) if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...)) nbd_config_put -> due to step 1), reference is still not zero 3) nbd_genl_reconfigure() queue recv_work() again; nbd_genl_reconfigure config = nbd_get_config_unlocked(nbd) if (!config) -> succeed if (!test_bit(NBD_RT_BOUND, ...)) -> succeed nbd_reconnect_socket queue_work(nbd->recv_workq, &args->work) 4) step 1) release the reference; 5) Finially, recv_work() will trigger UAF: recv_work nbd_config_put(nbd) -> nbd_config is freed atomic_dec(&config->recv_threads) -> UAF Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so that nbd_genl_reconfigure() will fail. CVE-2025-21731 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: ftrace: Avoid potential division by zero in function_stat_show() Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64} produce zero and skip stddev computation in that case. For now don't care about rec->counter * rec->counter overflow because rec->time * rec->time overflow will likely happen earlier. CVE-2025-21898 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: vlan: enforce underlying device type Currently, VLAN devices can be created on top of non-ethernet devices. Besides the fact that it doesn't make much sense, this also causes a bug which leaks the address of a kernel function to usermode. When creating a VLAN device, we initialize GARP (garp_init_applicant) and MRP (mrp_init_applicant) for the underlying device. As part of the initialization process, we add the multicast address of each applicant to the underlying device, by calling dev_mc_add. __dev_mc_add uses dev->addr_len to determine the length of the new multicast address. This causes an out-of-bounds read if dev->addr_len is greater than 6, since the multicast addresses provided by GARP and MRP are only 6 bytes long. This behaviour can be reproduced using the following commands: ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo ip l set up dev gretest ip link add link gretest name vlantest type vlan id 100 Then, the following command will display the address of garp_pdu_rcv: ip maddr show | grep 01:80:c2:00:00:21 Fix the bug by enforcing the type of the underlying device during VLAN device initialization. CVE-2025-21920 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove() The system can experience a random crash a few minutes after the driver is removed. This issue occurs due to improper handling of memory freeing in the ishtp_hid_remove() function. The function currently frees the `driver_data` directly within the loop that destroys the HID devices, which can lead to accessing freed memory. Specifically, `hid_destroy_device()` uses `driver_data` when it calls `hid_ishtp_set_feature()` to power off the sensor, so freeing `driver_data` beforehand can result in accessing invalid memory. This patch resolves the issue by storing the `driver_data` in a temporary variable before calling `hid_destroy_device()`, and then freeing the `driver_data` after the device is destroyed. CVE-2025-21928 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net_sched: Prevent creation of classes with TC_H_ROOT The function qdisc_tree_reduce_backlog() uses TC_H_ROOT as a termination condition when traversing up the qdisc tree to update parent backlog counters. However, if a class is created with classid TC_H_ROOT, the traversal terminates prematurely at this class instead of reaching the actual root qdisc, causing parent statistics to be incorrectly maintained. In case of DRR, this could lead to a crash as reported by Mingi Cho. Prevent the creation of any Qdisc class with classid TC_H_ROOT (0xFFFFFFFF) across all qdisc types, as suggested by Jamal. CVE-2025-21971 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Apply the link chain quirk on NEC isoc endpoints Two clearly different specimens of NEC uPD720200 (one with start/stop bug, one without) were seen to cause IOMMU faults after some Missed Service Errors. Faulting address is immediately after a transfer ring segment and patched dynamic debug messages revealed that the MSE was received when waiting for a TD near the end of that segment: [ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0 [ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000] [ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000] It gets even funnier if the next page is a ring segment accessible to the HC. Below, it reports MSE in segment at ff1e8000, plows through a zero-filled page at ff1e9000 and starts reporting events for TRBs in page at ff1ea000 every microframe, instead of jumping to seg ff1e6000. [ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag. [ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 At some point completion events change from Isoch Buffer Overrun to Short Packet and the HC finally finds cycle bit mismatch in ff1ec000. [ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2 It's possible that data from the isochronous device were written to random buffers of pending TDs on other endpoints (either IN or OUT), other devices or even other HCs in the same IOMMU domain. Lastly, an error from a different USB device on another HC. Was it caused by the above? I don't know, but it may have been. The disk was working without any other issues and generated PCIe traffic to starve the NEC of upstream BW and trigger those MSEs. The two HCs shared one x1 slot by means of a commercial "PCIe splitter" board. [ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00 [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0 Fortunately, it appears that this ridiculous bug is avoided by setting the chain bit of Link TRBs on isochronous rings. Other ancient HCs are known which also expect the bit to be set and they ignore Link TRBs if it's not. Reportedly, 0.95 spec guaranteed that the bit is set. The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports tens of MSEs per second and runs into the bug within seconds. Chaining Link TRBs allows the same workload to run for many minutes, many times. No ne ---truncated--- CVE-2025-22022 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free in print_graph_function_flags during tracer switching Kairui reported a UAF issue in print_graph_function_flags() during ftrace stress testing [1]. This issue can be reproduced if puting a 'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(), and executing the following script: $ echo function_graph > current_tracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > current_tracer The root cause lies in the two calls to print_graph_function_flags within print_trace_line during each s_show(): * One through 'iter->trace->print_line()'; * Another through 'event->funcs->trace()', which is hidden in print_trace_fmt() before print_trace_line returns. Tracer switching only updates the former, while the latter continues to use the print_line function of the old tracer, which in the script above is print_graph_function_flags. Moreover, when switching from the 'function_graph' tracer to the 'timerlat' tracer, s_start only calls graph_trace_close of the 'function_graph' tracer to free 'iter->private', but does not set it to NULL. This provides an opportunity for 'event->funcs->trace()' to use an invalid 'iter->private'. To fix this issue, set 'iter->private' to NULL immediately after freeing it in graph_trace_close(), ensuring that an invalid pointer is not passed to other tracers. Additionally, clean up the unnecessary 'iter->private = NULL' during each 'cat trace' when using wakeup and irqsoff tracers. [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/ CVE-2025-22035 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate An attacker can pass a malicious malformed token which causes unexpected memory to be consumed during parsing. CVE-2025-22868 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:docker-28.4.0_ce-98.140.1 important SSH servers which implement file transfer protocols are vulnerable to a denial of service attack from clients which complete the key exchange slowly, or not at all, causing pending content to be read into memory, but never transmitted. CVE-2025-22869 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:docker-28.4.0_ce-98.140.1 important The tokenizer incorrectly interprets tags with unquoted attribute values that end with a solidus character (/) as self-closing. When directly using Tokenizer, this can result in such tags incorrectly being marked as self-closing, and when using the Parse functions, this can result in content following such tags as being placed in the wrong scope during DOM construction, but only when tags are in foreign content (e.g. <math>, <svg>, etc contexts). CVE-2025-22872 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:docker-28.4.0_ce-98.140.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses Acquire a lock on kvm->srcu when userspace is getting MP state to handle a rather extreme edge case where "accepting" APIC events, i.e. processing pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU is in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP state will trigger a nested VM-Exit by way of ->check_nested_events(), and emuating the nested VM-Exit can access guest memory. The splat was originally hit by syzkaller on a Google-internal kernel, and reproduced on an upstream kernel by hacking the triple_fault_event_test selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario. ============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted ----------------------------- include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm] stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> CVE-2025-23141 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: vlan: don't propagate flags on open With the device instance lock, there is now a possibility of a deadlock: [ 1.211455] ============================================ [ 1.211571] WARNING: possible recursive locking detected [ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted [ 1.211823] -------------------------------------------- [ 1.211936] ip/184 is trying to acquire lock: [ 1.212032] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0 [ 1.212207] [ 1.212207] but task is already holding lock: [ 1.212332] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0 [ 1.212487] [ 1.212487] other info that might help us debug this: [ 1.212626] Possible unsafe locking scenario: [ 1.212626] [ 1.212751] CPU0 [ 1.212815] ---- [ 1.212871] lock(&dev->lock); [ 1.212944] lock(&dev->lock); [ 1.213016] [ 1.213016] *** DEADLOCK *** [ 1.213016] [ 1.213143] May be due to missing lock nesting notation [ 1.213143] [ 1.213294] 3 locks held by ip/184: [ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0 [ 1.213543] #1: ffffffff84e5fc70 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0 [ 1.213727] #2: ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0 [ 1.213895] [ 1.213895] stack backtrace: [ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 [ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [ 1.213994] Call Trace: [ 1.213995] <TASK> [ 1.213996] dump_stack_lvl+0x8e/0xd0 [ 1.214000] print_deadlock_bug+0x28b/0x2a0 [ 1.214020] lock_acquire+0xea/0x2a0 [ 1.214027] __mutex_lock+0xbf/0xd40 [ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev->flags & IFF_ALLMULTI [ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev [ 1.214042] __dev_open+0x145/0x270 [ 1.214046] __dev_change_flags+0xb0/0x1e0 [ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev [ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev->vlan_info [ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0 [ 1.214058] notifier_call_chain+0x78/0x120 [ 1.214062] netif_open+0x6d/0x90 [ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0 [ 1.214066] bond_enslave+0x64c/0x1230 [ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0 [ 1.214077] do_setlink+0x516/0x13b0 [ 1.214094] rtnl_newlink+0xaba/0xb80 [ 1.214132] rtnetlink_rcv_msg+0x440/0x490 [ 1.214144] netlink_rcv_skb+0xeb/0x120 [ 1.214150] netlink_unicast+0x1f9/0x320 [ 1.214153] netlink_sendmsg+0x346/0x3f0 [ 1.214157] __sock_sendmsg+0x86/0xb0 [ 1.214160] ____sys_sendmsg+0x1c8/0x220 [ 1.214164] ___sys_sendmsg+0x28f/0x2d0 [ 1.214179] __x64_sys_sendmsg+0xef/0x140 [ 1.214184] do_syscall_64+0xec/0x1d0 [ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 1.214191] RIP: 0033:0x7f2d1b4a7e56 Device setup: netdevsim0 (down) ^ ^ bond netdevsim1.100@netdevsim1 allmulticast=on (down) When we enslave the lower device (netdevsim0) which has a vlan, we propagate vlan's allmuti/promisc flags during ndo_open. This causes (re)locking on of the real_dev. Propagate allmulti/promisc on flags change, not on the open. There is a slight semantics change that vlans that are down now propagate the flags, but this seems unlikely to result in the real issues. Reproducer: echo 0 1 > /sys/bus/netdevsim/new_device dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*) dev=$(echo $dev_path | rev | cut -d/ -f1 | rev) ip link set dev $dev name netdevsim0 ip link set dev netdevsim0 up ip link add link netdevsim0 name netdevsim0.100 type vlan id 100 ip link set dev netdevsim0.100 allm ---truncated--- CVE-2025-23163 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate A heap-buffer-overflow (off-by-one) flaw was found in the GnuTLS software in the template parsing logic within the certtool utility. When it reads certain settings from a template file, it allows an attacker to cause an out-of-bounds (OOB) NULL pointer write, resulting in memory corruption and a denial-of-service (DoS) that could potentially crash the system. CVE-2025-32990 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libgnutls30-3.4.17-8.20.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: tls: explicitly disallow disconnect syzbot discovered that it can disconnect a TLS socket and then run into all sort of unexpected corner cases. I have a vague recollection of Eric pointing this out to us a long time ago. Supporting disconnect is really hard, for one thing if offload is enabled we'd need to wait for all packets to be _acked_. Disconnect is not commonly used, disallow it. The immediate problem syzbot run into is the warning in the strp, but that's just the easiest bug to trigger: WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: <TASK> tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237 CVE-2025-37756 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: tipc: fix memory leak in tipc_link_xmit In case the backlog transmit queue for system-importance messages is overloaded, tipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads to memory leak and failure when a skb is allocated. This commit fixes this issue by purging the skb list before tipc_link_xmit() returns. CVE-2025-37757 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog() After making all ->qlen_notify() callbacks idempotent, now it is safe to remove the check of qlen!=0 from both fq_codel_dequeue() and codel_qdisc_dequeue(). CVE-2025-37798 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: driver core: fix potential NULL pointer dereference in dev_uevent() If userspace reads "uevent" device attribute at the same time as another threads unbinds the device from its driver, change to dev->driver from a valid pointer to NULL may result in crash. Fix this by using READ_ONCE() when fetching the pointer, and take bus' drivers klist lock to make sure driver instance will not disappear while we access it. Use WRITE_ONCE() when setting the driver pointer to ensure there is no tearing. CVE-2025-37800 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: harden block_group::bg_list against list_del() races As far as I can tell, these calls of list_del_init() on bg_list cannot run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(), as they are in transaction error paths and situations where the block group is readonly. However, if there is any chance at all of racing with mark_bg_unused(), or a different future user of bg_list, better to be safe than sorry. Otherwise we risk the following interleaving (bg_list refcount in parens) T1 (some random op) T2 (btrfs_mark_bg_unused) !list_empty(&bg->bg_list); (1) list_del_init(&bg->bg_list); (1) list_move_tail (1) btrfs_put_block_group (0) btrfs_delete_unused_bgs bg = list_first_entry list_del_init(&bg->bg_list); btrfs_put_block_group(bg); (-1) Ultimately, this results in a broken ref count that hits zero one deref early and the real final deref underflows the refcount, resulting in a WARNING. CVE-2025-37856 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reset IRTE to host control if *new* route isn't postable Restore an IRTE back to host control (remapped or posted MSI mode) if the *new* GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU. The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn't freed. CVE-2025-37885 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: mtd: inftlcore: Add error check for inftl_read_oob() In INFTL_findwriteunit(), the return value of inftl_read_oob() need to be checked. A proper implementation can be found in INFTL_deleteblock(). The status will be set as SECTOR_IGNORE to break from the while-loop correctly if the inftl_read_oob() fails. CVE-2025-37892 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix out-of-bound memcpy() during ethtool -w When retrieving the FW coredump using ethtool, it can sometimes cause memory corruption: BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45): __bnxt_get_coredump+0x3ef/0x670 [bnxt_en] ethtool_get_dump_data+0xdc/0x1a0 __dev_ethtool+0xa1e/0x1af0 dev_ethtool+0xa8/0x170 dev_ioctl+0x1b5/0x580 sock_do_ioctl+0xab/0xf0 sock_ioctl+0x1ce/0x2e0 __x64_sys_ioctl+0x87/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x78/0x80 ... This happens when copying the coredump segment list in bnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command. The info->dest_buf buffer is allocated based on the number of coredump segments returned by the FW. The segment list is then DMA'ed by the FW and the length of the DMA is returned by FW. The driver then copies this DMA'ed segment list to info->dest_buf. In some cases, this DMA length may exceed the info->dest_buf length and cause the above BUG condition. Fix it by capping the copy length to not exceed the length of info->dest_buf. The extra DMA data contains no useful information. This code path is shared for the HWRM_DBG_COREDUMP_LIST and the HWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is different for these 2 FW commands. To simplify the logic, we need to move the line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE up, so that the new check to cap the copy length will work for both commands. CVE-2025-37911 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: xsk: Fix race condition in AF_XDP generic RX path Move rx_lock from xsk_socket to xsk_buff_pool. Fix synchronization for shared umem mode in generic RX path where multiple sockets share single xsk_buff_pool. RX queue is exclusive to xsk_socket, while FILL queue can be shared between multiple sockets. This could result in race condition where two CPU cores access RX path of two different sockets sharing the same umem. Protect both queues by acquiring spinlock in shared xsk_buff_pool. Lock contention may be minimized in the future by some per-thread FQ buffering. It's safe and necessary to move spin_lock_bh(rx_lock) after xsk_rcv_check(): * xs->pool and spinlock_init is synchronized by xsk_bind() -> xsk_is_bound() memory barriers. * xsk_rcv_check() may return true at the moment of xsk_release() or xsk_unbind_dev(), however this will not cause any data races or race conditions. xsk_unbind_dev() removes xdp socket from all maps and waits for completion of all outstanding rx operations. Packets in RX path will either complete safely or drop. CVE-2025-37920 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: tracing: Fix oob write in trace_seq_to_buffer() syzbot reported this bug: ================================================================== BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline] BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260 CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106 trace_seq_to_buffer kernel/trace/trace.c:1830 [inline] tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 .... ================================================================== It has been reported that trace_seq_to_buffer() tries to copy more data than PAGE_SIZE to buf. Therefore, to prevent this, we should use the smaller of trace_seq_used(&iter->seq) and PAGE_SIZE as an argument. CVE-2025-37923 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256. The same applies to the hid string with length 13 and uid string with length 250. Check the length of hid and uid strings separately to prevent buffer overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. CVE-2025-37927 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm-bufio: don't schedule in atomic context A BUG was reported as below when CONFIG_DEBUG_ATOMIC_SLEEP and try_verify_in_tasklet are enabled. [ 129.444685][ T934] BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2421 [ 129.444723][ T934] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 934, name: kworker/1:4 [ 129.444740][ T934] preempt_count: 201, expected: 0 [ 129.444756][ T934] RCU nest depth: 0, expected: 0 [ 129.444781][ T934] Preemption disabled at: [ 129.444789][ T934] [<ffffffd816231900>] shrink_work+0x21c/0x248 [ 129.445167][ T934] kernel BUG at kernel/sched/walt/walt_debug.c:16! [ 129.445183][ T934] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [ 129.445204][ T934] Skip md ftrace buffer dump for: 0x1609e0 [ 129.447348][ T934] CPU: 1 PID: 934 Comm: kworker/1:4 Tainted: G W OE 6.6.56-android15-8-o-g6f82312b30b9-debug #1 1400000003000000474e5500b3187743670464e8 [ 129.447362][ T934] Hardware name: Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT) [ 129.447373][ T934] Workqueue: dm_bufio_cache shrink_work [ 129.447394][ T934] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 129.447406][ T934] pc : android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug] [ 129.447435][ T934] lr : __traceiter_android_rvh_schedule_bug+0x44/0x6c [ 129.447451][ T934] sp : ffffffc0843dbc90 [ 129.447459][ T934] x29: ffffffc0843dbc90 x28: ffffffffffffffff x27: 0000000000000c8b [ 129.447479][ T934] x26: 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68 [ 129.447497][ T934] x23: ffffff805171c5b4 x22: 0000000000000000 x21: ffffffd816231900 [ 129.447517][ T934] x20: ffffff80306ba898 x19: 0000000000000000 x18: ffffffc084159030 [ 129.447535][ T934] x17: 00000000d2b5dd1f x16: 00000000d2b5dd1f x15: ffffffd816720358 [ 129.447554][ T934] x14: 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003 [ 129.447572][ T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9 : 7e779c5735de9400 [ 129.447591][ T934] x8 : ffffffd81560d004 x7 : 205b5d3938373434 x6 : ffffffd8167397c8 [ 129.447610][ T934] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffffffc0843db9e0 [ 129.447629][ T934] x2 : 0000000000002f15 x1 : 0000000000000000 x0 : 0000000000000000 [ 129.447647][ T934] Call trace: [ 129.447655][ T934] android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug 1400000003000000474e550080cce8a8a78606b6] [ 129.447681][ T934] __might_resched+0x190/0x1a8 [ 129.447694][ T934] shrink_work+0x180/0x248 [ 129.447706][ T934] process_one_work+0x260/0x624 [ 129.447718][ T934] worker_thread+0x28c/0x454 [ 129.447729][ T934] kthread+0x118/0x158 [ 129.447742][ T934] ret_from_fork+0x10/0x20 [ 129.447761][ T934] Code: ???????? ???????? ???????? d2b5dd1f (d4210000) [ 129.447772][ T934] ---[ end trace 0000000000000000 ]--- dm_bufio_lock will call spin_lock_bh when try_verify_in_tasklet is enabled, and __scan will be called in atomic context. CVE-2025-37928 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipvs: fix uninit-value for saddr in do_output_route4 syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 ("ipvs: do not use random local source address for tunnels") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to ret_saddr. [1] BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e Uninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8e CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engi ---truncated--- CVE-2025-37961 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: block: fix resource leak in blk_register_queue() error path When registering a queue fails after blk_mq_sysfs_register() is successful but the function later encounters an error, we need to clean up the blk_mq_sysfs resources. Add the missing blk_mq_sysfs_unregister() call in the error path to properly clean up these resources and prevent a memory leak. CVE-2025-37980 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: wl1251: fix memory leak in wl1251_tx_work The skb dequeued from tx_queue is lost when wl1251_ps_elp_wakeup fails with a -ETIMEDOUT error. Fix that by queueing the skb back to tx_queue. CVE-2025-37982 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net_sched: Flush gso_skb list too during ->change() Previously, when reducing a qdisc's limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gso_skb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q.qlen. This patch introduces a new helper, qdisc_dequeue_internal(), which ensures both the gso_skb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie) are updated to use this helper in their ->change() routines. CVE-2025-37992 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: module: ensure that kobject_put() is safe for module type kobjects In 'lookup_or_create_module_kobject()', an internal kobject is created using 'module_ktype'. So call to 'kobject_put()' on error handling path causes an attempt to use an uninitialized completion pointer in 'module_kobject_release()'. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether 'complete()' is actually required makes 'kobject_put()' safe. CVE-2025-37995 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: openvswitch: Fix unsafe attribute parsing in output_userspace() This patch replaces the manual Netlink attribute iteration in output_userspace() with nla_for_each_nested(), which ensures that only well-formed attributes are processed. CVE-2025-37998 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 low In the Linux kernel, the following vulnerability has been resolved: sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue() When enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the child qdisc's peek() operation before incrementing sch->q.qlen and sch->qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may trigger an immediate dequeue and potential packet drop. In such cases, qdisc_tree_reduce_backlog() is called, but the HFSC qdisc's qlen and backlog have not yet been updated, leading to inconsistent queue accounting. This can leave an empty HFSC class in the active list, causing further consequences like use-after-free. This patch fixes the bug by moving the increment of sch->q.qlen and sch->qstats.backlog before the call to the child qdisc's peek() operation. This ensures that queue length and backlog are always accurate when packet drops or dequeues are triggered during the peek. CVE-2025-38000 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking for bcm_op runtime updates The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The content and also the length of the sequence can be changed resp reduced at runtime where the 'currframe' counter is then set to zero. Although this appeared to be a safe operation the updates of 'currframe' can be triggered from user space and hrtimer context in bcm_can_tx(). Anderson Nascimento created a proof of concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh. At the rework of bcm_can_tx() the 'count' variable has been moved into the protected section as this variable can be modified from both contexts too. CVE-2025-38004 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfs: handle failure of nfs_get_lock_context in unlock path When memory is insufficient, the allocation of nfs_lock_context in nfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat an nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM) as valid and proceed to execute rpc_run_task(), this will trigger a NULL pointer dereference in nfs4_locku_prepare. For example: BUG: kernel NULL pointer dereference, address: 000000000000000c PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 Workqueue: rpciod rpc_async_schedule RIP: 0010:nfs4_locku_prepare+0x35/0xc2 Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3 RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246 RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40 RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38 R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030 R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30 FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0 Call Trace: <TASK> __rpc_execute+0xbc/0x480 rpc_async_schedule+0x2f/0x40 process_one_work+0x232/0x5d0 worker_thread+0x1da/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x240 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: CR2: 000000000000000c ---[ end trace 0000000000000000 ]--- Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails and return NULL to terminate subsequent rpc_run_task, preventing NULL pointer dereference. CVE-2025-38023 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f In the function rxe_create_cq, when rxe_cq_from_init fails, the function rxe_cleanup will be called to handle the allocated resources. In fact, some memory resources have already been freed in the function rxe_cq_from_init. Thus, this problem will occur. The solution is to let rxe_cleanup do all the work. CVE-2025-38024 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref btrfs_prelim_ref() calls the old and new reference variables in the incorrect order. This causes a NULL pointer dereference because oldref is passed as NULL to trace_btrfs_prelim_ref_insert(). Note, trace_btrfs_prelim_ref_insert() is being called with newref as oldref (and oldref as NULL) on purpose in order to print out the values of newref. To reproduce: echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable Perform some writeback operations. Backtrace: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary) 7ca2cef72d5e9c600f0c7718adb6462de8149622 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130 Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88 RSP: 0018:ffffce44820077a0 EFLAGS: 00010286 RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010 R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000 R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540 FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> prelim_ref_insert+0x1c1/0x270 find_parent_nodes+0x12a6/0x1ee0 ? __entry_text_end+0x101f06/0x101f09 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 btrfs_is_data_extent_shared+0x167/0x640 ? fiemap_process_hole+0xd0/0x2c0 extent_fiemap+0xa5c/0xbc0 ? __entry_text_end+0x101f05/0x101f09 btrfs_fiemap+0x7e/0xd0 do_vfs_ioctl+0x425/0x9d0 __x64_sys_ioctl+0x75/0xc0 CVE-2025-38034 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: don't restore null sk_state_change queue->state_change is set as part of nvmet_tcp_set_queue_sock(), but if the TCP connection isn't established when nvmet_tcp_set_queue_sock() is called then queue->state_change isn't set and sock->sk->sk_state_change isn't replaced. As such we don't need to restore sock->sk->sk_state_change if queue->state_change is NULL. This avoids NULL pointer dereferences such as this: [ 286.462026][ C0] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 286.462814][ C0] #PF: supervisor instruction fetch in kernel mode [ 286.463796][ C0] #PF: error_code(0x0010) - not-present page [ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0 [ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI [ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary) [ 286.466393][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 [ 286.467147][ C0] RIP: 0010:0x0 [ 286.467420][ C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246 [ 286.468425][ C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43 [ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100 [ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c [ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3 [ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268 [ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000 [ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0 [ 286.473500][ C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 286.474467][ C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 [ 286.475453][ C0] Call Trace: [ 286.476102][ C0] <IRQ> [ 286.476719][ C0] tcp_fin+0x2bb/0x440 [ 286.477429][ C0] tcp_data_queue+0x190f/0x4e60 [ 286.478174][ C0] ? __build_skb_around+0x234/0x330 [ 286.478940][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.479659][ C0] ? __pfx_tcp_data_queue+0x10/0x10 [ 286.480431][ C0] ? tcp_try_undo_loss+0x640/0x6c0 [ 286.481196][ C0] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 286.482046][ C0] ? kvm_clock_get_cycles+0x14/0x30 [ 286.482769][ C0] ? ktime_get+0x66/0x150 [ 286.483433][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.484146][ C0] tcp_rcv_established+0x6e4/0x2050 [ 286.484857][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.485523][ C0] ? ipv4_dst_check+0x160/0x2b0 [ 286.486203][ C0] ? __pfx_tcp_rcv_established+0x10/0x10 [ 286.486917][ C0] ? lock_release+0x217/0x2c0 [ 286.487595][ C0] tcp_v4_do_rcv+0x4d6/0x9b0 [ 286.488279][ C0] tcp_v4_rcv+0x2af8/0x3e30 [ 286.488904][ C0] ? raw_local_deliver+0x51b/0xad0 [ 286.489551][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.490198][ C0] ? __pfx_tcp_v4_rcv+0x10/0x10 [ 286.490813][ C0] ? __pfx_raw_local_deliver+0x10/0x10 [ 286.491487][ C0] ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack] [ 286.492275][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.492900][ C0] ip_protocol_deliver_rcu+0x8f/0x370 [ 286.493579][ C0] ip_local_deliver_finish+0x297/0x420 [ 286.494268][ C0] ip_local_deliver+0x168/0x430 [ 286.494867][ C0] ? __pfx_ip_local_deliver+0x10/0x10 [ 286.495498][ C0] ? __pfx_ip_local_deliver_finish+0x10/0x10 [ 286.496204][ C0] ? ip_rcv_finish_core+0x19a/0x1f20 [ 286.496806][ C0] ? lock_release+0x217/0x2c0 [ 286.497414][ C0] ip_rcv+0x455/0x6e0 [ 286.497945][ C0] ? __pfx_ip_rcv+0x10/0x10 [ ---truncated--- CVE-2025-38035 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: serial: mctrl_gpio: split disable_ms into sync and no_sync APIs The following splat has been observed on a SAMA5D27 platform using atmel_serial: BUG: sleeping function called from invalid context at kernel/irq/manage.c:738 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0 preempt_count: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<00000000>] 0x0 hardirqs last disabled at (0): [<c01588f0>] copy_process+0x1c4c/0x7bec softirqs last enabled at (0): [<c0158944>] copy_process+0x1ca0/0x7bec softirqs last disabled at (0): [<00000000>] 0x0 CPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74 Hardware name: Atmel SAMA5 Workqueue: hci0 hci_power_on [bluetooth] Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x44/0x70 dump_stack_lvl from __might_resched+0x38c/0x598 __might_resched from disable_irq+0x1c/0x48 disable_irq from mctrl_gpio_disable_ms+0x74/0xc0 mctrl_gpio_disable_ms from atmel_disable_ms.part.0+0x80/0x1f4 atmel_disable_ms.part.0 from atmel_set_termios+0x764/0x11e8 atmel_set_termios from uart_change_line_settings+0x15c/0x994 uart_change_line_settings from uart_set_termios+0x2b0/0x668 uart_set_termios from tty_set_termios+0x600/0x8ec tty_set_termios from ttyport_set_flow_control+0x188/0x1e0 ttyport_set_flow_control from wilc_setup+0xd0/0x524 [hci_wilc] wilc_setup [hci_wilc] from hci_dev_open_sync+0x330/0x203c [bluetooth] hci_dev_open_sync [bluetooth] from hci_dev_do_open+0x40/0xb0 [bluetooth] hci_dev_do_open [bluetooth] from hci_power_on+0x12c/0x664 [bluetooth] hci_power_on [bluetooth] from process_one_work+0x998/0x1a38 process_one_work from worker_thread+0x6e0/0xfb4 worker_thread from kthread+0x3d4/0x484 kthread from ret_from_fork+0x14/0x28 This warning is emitted when trying to toggle, at the highest level, some flow control (with serdev_device_set_flow_control) in a device driver. At the lowest level, the atmel_serial driver is using serial_mctrl_gpio lib to enable/disable the corresponding IRQs accordingly. The warning emitted by CONFIG_DEBUG_ATOMIC_SLEEP is due to disable_irq (called in mctrl_gpio_disable_ms) being possibly called in some atomic context (some tty drivers perform modem lines configuration in regions protected by port lock). Split mctrl_gpio_disable_ms into two differents APIs, a non-blocking one and a blocking one. Replace mctrl_gpio_disable_ms calls with the relevant version depending on whether the call is protected by some port lock. CVE-2025-38040 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free in cifs_fill_dirent There is a race condition in the readdir concurrency process, which may access the rsp buffer after it has been released, triggering the following KASAN warning. ================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975 CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 </TASK> Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== POC is available in the link [1]. The problem triggering process is as follows: Process 1 Process 2 ----------------------------------- ---truncated--- CVE-2025-38051 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock ... or we risk stealing final mntput from sync umount - raising mnt_count after umount(2) has verified that victim is not busy, but before it has set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't see that it's safe to quietly undo mnt_count increment and leaves dropping the reference to caller, where it'll be a full-blown mntput(). Check under mount_lock is needed; leaving the current one done before taking that makes no sense - it's nowhere near common enough to bother with. CVE-2025-38058 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 low In the Linux kernel, the following vulnerability has been resolved: net: pktgen: fix access outside of user given buffer in pktgen_thread_write() Honour the user given buffer size for the strn_len() calls (otherwise strn_len() will access memory outside of the user given buffer). CVE-2025-38061 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: virtio: break and reset virtio devices on device_shutdown() Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory accesses during the hang. Invalid read at addr 0x102877002, size 2, region '(null)', reason: rejected Invalid write at addr 0x102877A44, size 2, region '(null)', reason: rejected ... It was traced down to virtio-console. Kexec works fine if virtio-console is not in use. The issue is that virtio-console continues to write to the MMIO even after underlying virtio-pci device is reset. Additionally, Eric noticed that IOMMUs are reset before devices, if devices are not reset on shutdown they continue to poke at guest memory and get errors from the IOMMU. Some devices get wedged then. The problem can be solved by breaking all virtio devices on virtio bus shutdown, then resetting them. CVE-2025-38064 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: crypto: lzo - Fix compression buffer overrun Unlike the decompression code, the compression code in LZO never checked for output overruns. It instead assumes that the caller always provides enough buffer space, disregarding the buffer length provided by the caller. Add a safe compression interface that checks for the end of buffer before each write. Use the safe interface in crypto/lzo. CVE-2025-38068 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: libnvdimm/labels: Fix divide error in nd_label_data_init() If a faulty CXL memory device returns a broken zero LSA size in its memory device information (Identify Memory Device (Opcode 4000h), CXL spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm driver: Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm] Code and flow: 1) CXL Command 4000h returns LSA size = 0 2) config_size is assigned to zero LSA size (CXL pmem driver): drivers/cxl/pmem.c: .config_size = mds->lsa_size, 3) max_xfer is set to zero (nvdimm driver): drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size); 4) A subsequent DIV_ROUND_UP() causes a division by zero: drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */ drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer, drivers/nvdimm/label.c- config_size); Fix this by checking the config size parameter by extending an existing check. CVE-2025-38072 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: vhost-scsi: protect vq->log_used with vq->mutex The vhost-scsi completion path may access vq->log_base when vq->log_used is already set to false. vhost-thread QEMU-thread vhost_scsi_complete_cmd_work() -> vhost_add_used() -> vhost_add_used_n() if (unlikely(vq->log_used)) QEMU disables vq->log_used via VHOST_SET_VRING_ADDR. mutex_lock(&vq->mutex); vq->log_used = false now! mutex_unlock(&vq->mutex); QEMU gfree(vq->log_base) log_used() -> log_write(vq->log_base) Assuming the VMM is QEMU. The vq->log_base is from QEMU userpace and can be reclaimed via gfree(). As a result, this causes invalid memory writes to QEMU userspace. The control queue path has the same issue. CVE-2025-38074 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix timeout on deleted connection NOPIN response timer may expire on a deleted connection and crash with such logs: Did not receive response to NOPIN on CID: 0, failing connection for I_T Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d BUG: Kernel NULL pointer dereference on read at 0x00000000 NIP strlcpy+0x8/0xb0 LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod] Call Trace: iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod] call_timer_fn+0x58/0x1f0 run_timer_softirq+0x740/0x860 __do_softirq+0x16c/0x420 irq_exit+0x188/0x1c0 timer_interrupt+0x184/0x410 That is because nopin response timer may be re-started on nopin timer expiration. Stop nopin timer before stopping the nopin response timer to be sure that no one of them will be re-started. CVE-2025-38075 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race of buffer access at PCM OSS layer The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of snd_pcm_format_set_silence() with runtime->dma_area. But this may lead to a UAF because the accessed runtime->dma_area might be freed concurrently, as it's performed outside the PCM ops. For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation. CVE-2025-38078 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: crypto: algif_hash - fix double free in hash_accept If accept(2) is called on socket type algif_hash with MSG_MORE flag set and crypto_ahash_import fails, sk2 is freed. However, it is also freed in af_alg_release, leading to slab-use-after-free error. CVE-2025-38079 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: net_sched: prio: fix a race in prio_tune() Gerrard Tai reported a race condition in PRIO, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. CVE-2025-38083 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: net: cadence: macb: Fix a possible deadlock in macb_halt_tx. There is a situation where after THALT is set high, TGO stays high as well. Because jiffies are never updated, as we are in a context with interrupts disabled, we never exit that loop and have a deadlock. That deadlock was noticed on a sama5d4 device that stayed locked for days. Use retries instead of jiffies so that the timeout really works and we do not have a deadlock anymore. CVE-2025-38094 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify During our test, it is found that a warning can be trigger in try_grab_folio as follow: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: <TASK> follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]--- Digging into the source, context->notify_page may init by get_user_pages_fast and can be seen in vmci_ctx_unset_notify which will try to put_page. However get_user_pages_fast is not finished here and lead to following try_grab_folio warning. The race condition is shown as follow: cpu0 cpu1 vmci_host_do_set_notify vmci_host_setup_notify get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page); lockless_pages_from_mm gup_pgd_range gup_huge_pmd // update &context->notify_page vmci_host_do_set_notify vmci_ctx_unset_notify notify_page = context->notify_page; if (notify_page) put_page(notify_page); // page is freed __gup_longterm_locked __get_user_pages follow_trans_huge_pmd try_grab_folio // warn here To slove this, use local variable page to make notify_page can be seen after finish get_user_pages_fast. CVE-2025-38102 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse() Update struct hid_descriptor to better reflect the mandatory and optional parts of the HID Descriptor as per USB HID 1.11 specification. Note: the kernel currently does not parse any optional HID class descriptors, only the mandatory report descriptor. Update all references to member element desc[0] to rpt_desc. Add test to verify bLength and bNumDescriptors values are valid. Replace the for loop with direct access to the mandatory HID class descriptor member for the report descriptor. This eliminates the possibility of getting an out-of-bounds fault. Add a warning message if the HID descriptor contains any unsupported optional HID class descriptors. CVE-2025-38103 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 low In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Kill timer properly at removal The USB-audio MIDI code initializes the timer, but in a rare case, the driver might be freed without the disconnect call. This leaves the timer in an active state while the assigned object is released via snd_usbmidi_free(), which ends up with a kernel warning when the debug configuration is enabled, as spotted by fuzzer. For avoiding the problem, put timer_shutdown_sync() at snd_usbmidi_free(), so that the timer can be killed properly. While we're at it, replace the existing timer_delete_sync() at the disconnect callback with timer_shutdown_sync(), too. CVE-2025-38105 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net_sched: red: fix a race in __red_change() Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. CVE-2025-38108 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: Fix TOCTOU issue in sk_is_readable() sk->sk_prot->sock_is_readable is a valid function pointer when sk resides in a sockmap. After the last sk_psock_put() (which usually happens when socket is removed from sockmap), sk->sk_prot gets restored and sk->sk_prot->sock_is_readable becomes NULL. This makes sk_is_readable() racy, if the value of sk->sk_prot is reloaded after the initial check. Which in turn may lead to a null pointer dereference. Ensure the function pointer does not turn NULL after the check. CVE-2025-38112 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net_sched: sch_sfq: fix a potential crash on gso_skb handling SFQ has an assumption of always being able to queue at least one packet. However, after the blamed commit, sch->q.len can be inflated by packets in sch->gso_skb, and an enqueue() on an empty SFQ qdisc can be followed by an immediate drop. Fix sfq_drop() to properly clear q->tail in this situation. ip netns add lb ip link add dev to-lb type veth peer name in-lb netns lb ethtool -K to-lb tso off # force qdisc to requeue gso_skb ip netns exec lb ethtool -K in-lb gro on # enable NAPI ip link set dev to-lb up ip -netns lb link set dev in-lb up ip addr add dev to-lb 192.168.20.1/24 ip -netns lb addr add dev in-lb 192.168.20.2/24 tc qdisc replace dev to-lb root sfq limit 100 ip netns exec lb netserver netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & CVE-2025-38115 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Protect mgmt_pending list with its own lock This uses a mutex to protect from concurrent access of mgmt_pending list which can cause crashes like: ================================================================== BUG: KASAN: slab-use-after-free in hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 Read of size 2 at addr ffff0000c48885b2 by task syz.4.334/7318 CPU: 0 UID: 0 PID: 7318 Comm: syz.4.334 Not tainted 6.15.0-rc7-syzkaller-g187899f4124a #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_address_description+0xa8/0x254 mm/kasan/report.c:408 print_report+0x68/0x84 mm/kasan/report.c:521 kasan_report+0xb0/0x110 mm/kasan/report.c:634 __asan_report_load2_noabort+0x20/0x2c mm/kasan/report_generic.c:379 hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 mgmt_pending_find+0x7c/0x140 net/bluetooth/mgmt_util.c:223 pending_find net/bluetooth/mgmt.c:947 [inline] remove_adv_monitor+0x44/0x1a4 net/bluetooth/mgmt.c:5445 hci_mgmt_cmd+0x780/0xc00 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x544/0xbb0 net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x25c/0x378 net/socket.c:1131 new_sync_write fs/read_write.c:591 [inline] vfs_write+0x62c/0x97c fs/read_write.c:684 ksys_write+0x120/0x210 fs/read_write.c:736 __do_sys_write fs/read_write.c:747 [inline] __se_sys_write fs/read_write.c:744 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:744 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Allocated by task 7037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x54 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x9c/0xb4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4327 [inline] __kmalloc_noprof+0x2fc/0x4c8 mm/slub.c:4339 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xc4/0x1f0 net/core/sock.c:2198 sk_alloc+0x44/0x3ac net/core/sock.c:2254 bt_sock_alloc+0x4c/0x300 net/bluetooth/af_bluetooth.c:148 hci_sock_create+0xa8/0x194 net/bluetooth/hci_sock.c:2202 bt_sock_create+0x14c/0x24c net/bluetooth/af_bluetooth.c:132 __sock_create+0x43c/0x91c net/socket.c:1541 sock_create net/socket.c:1599 [inline] __sys_socket_create net/socket.c:1636 [inline] __sys_socket+0xd4/0x1c0 net/socket.c:1683 __do_sys_socket net/socket.c:1697 [inline] __se_sys_socket net/socket.c:1695 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1695 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Freed by task 6607: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_free_info+0x58/0x70 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x68/0x88 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline ---truncated--- CVE-2025-38117 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: gve: add missing NULL check for gve_alloc_pending_packet() in TX DQO gve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo() did not check for this case before dereferencing the returned pointer. Add a missing NULL check to prevent a potential NULL pointer dereference when allocation fails. This improves robustness in low-memory scenarios. CVE-2025-38122 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: stmmac: make sure that ptp_rate is not 0 before configuring timestamping The stmmac platform drivers that do not open-code the clk_ptp_rate value after having retrieved the default one from the device-tree can end up with 0 in clk_ptp_rate (as clk_get_rate can return 0). It will eventually propagate up to PTP initialization when bringing up the interface, leading to a divide by 0: Division by zero in kernel. CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.30-00001-g48313bd5768a #22 Hardware name: STM32 (Device Tree Support) Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x6c/0x8c dump_stack_lvl from Ldiv0_64+0x8/0x18 Ldiv0_64 from stmmac_init_tstamp_counter+0x190/0x1a4 stmmac_init_tstamp_counter from stmmac_hw_setup+0xc1c/0x111c stmmac_hw_setup from __stmmac_open+0x18c/0x434 __stmmac_open from stmmac_open+0x3c/0xbc stmmac_open from __dev_open+0xf4/0x1ac __dev_open from __dev_change_flags+0x1cc/0x224 __dev_change_flags from dev_change_flags+0x24/0x60 dev_change_flags from ip_auto_config+0x2e8/0x11a0 ip_auto_config from do_one_initcall+0x84/0x33c do_one_initcall from kernel_init_freeable+0x1b8/0x214 kernel_init_freeable from kernel_init+0x24/0x140 kernel_init from ret_from_fork+0x14/0x28 Exception stack(0xe0815fb0 to 0xe0815ff8) Prevent this division by 0 by adding an explicit check and error log about the actual issue. While at it, remove the same check from stmmac_ptp_register, which then becomes duplicate CVE-2025-38126 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: calipso: Don't call calipso functions for AF_INET sk. syzkaller reported a null-ptr-deref in txopt_get(). [0] The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo, so struct ipv6_pinfo was NULL there. However, this never happens for IPv6 sockets as inet_sk(sk)->pinet6 is always set in inet6_create(), meaning the socket was not IPv6 one. The root cause is missing validation in netlbl_conn_setattr(). netlbl_conn_setattr() switches branches based on struct sockaddr.sa_family, which is passed from userspace. However, netlbl_conn_setattr() does not check if the address family matches the socket. The syzkaller must have called connect() for an IPv6 address on an IPv4 socket. We have a proper validation in tcp_v[46]_connect(), but security_socket_connect() is called in the earlier stage. Let's copy the validation to netlbl_conn_setattr(). [0]: Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:txopt_get include/net/ipv6.h:390 [inline] RIP: 0010: Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00 RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212 RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00c RDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070 RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9e R10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00 R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80 FS: 00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0 PKRU: 80000000 Call Trace: <TASK> calipso_sock_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:557 netlbl_conn_setattr+0x10c/0x280 net/netlabel/netlabel_kapi.c:1177 selinux_netlbl_socket_connect_helper+0xd3/0x1b0 security/selinux/netlabel.c:569 selinux_netlbl_socket_connect_locked security/selinux/netlabel.c:597 [inline] selinux_netlbl_socket_connect+0xb6/0x100 security/selinux/netlabel.c:615 selinux_socket_connect+0x5f/0x80 security/selinux/hooks.c:4931 security_socket_connect+0x50/0xa0 security/security.c:4598 __sys_connect_file+0xa4/0x190 net/socket.c:2067 __sys_connect+0x12c/0x170 net/socket.c:2088 __do_sys_connect net/socket.c:2098 [inline] __se_sys_connect net/socket.c:2095 [inline] __x64_sys_connect+0x73/0xb0 net/socket.c:2095 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f901b61a12d Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f9019bd6fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f901b925fa0 RCX: 00007f901b61a12d RDX: 000000000000001c RSI: 0000200000000140 RDI: 0000000000000003 RBP: 00007f901b701505 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f901b5b62a0 R15: 00007f9019bb7000 </TASK> Modules linked in: CVE-2025-38147 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: fix error handling of usbnet read calls Syzkaller, courtesy of syzbot, identified an error (see report [1]) in aqc111 driver, caused by incomplete sanitation of usb read calls' results. This problem is quite similar to the one fixed in commit 920a9fa27e78 ("net: asix: add proper error handling of usb read errors"). For instance, usbnet_read_cmd() may read fewer than 'size' bytes, even if the caller expected the full amount, and aqc111_read_cmd() will not check its result properly. As [1] shows, this may lead to MAC address in aqc111_bind() being only partly initialized, triggering KMSAN warnings. Fix the issue by verifying that the number of bytes read is as expected and not less. [1] Partial syzbot report: BUG: KMSAN: uninit-value in is_valid_ether_addr include/linux/etherdevice.h:208 [inline] BUG: KMSAN: uninit-value in usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 is_valid_ether_addr include/linux/etherdevice.h:208 [inline] usbnet_probe+0x2e57/0x4390 drivers/net/usb/usbnet.c:1830 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] really_probe+0x4d1/0xd90 drivers/base/dd.c:658 __driver_probe_device+0x268/0x380 drivers/base/dd.c:800 ... Uninit was stored to memory at: dev_addr_mod+0xb0/0x550 net/core/dev_addr_lists.c:582 __dev_addr_set include/linux/netdevice.h:4874 [inline] eth_hw_addr_set include/linux/etherdevice.h:325 [inline] aqc111_bind+0x35f/0x1150 drivers/net/usb/aqc111.c:717 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 ... Uninit was stored to memory at: ether_addr_copy include/linux/etherdevice.h:305 [inline] aqc111_read_perm_mac drivers/net/usb/aqc111.c:663 [inline] aqc111_bind+0x794/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 usb_probe_interface+0xd01/0x1310 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:-1 [inline] ... Local variable buf.i created at: aqc111_read_perm_mac drivers/net/usb/aqc111.c:656 [inline] aqc111_bind+0x221/0x1150 drivers/net/usb/aqc111.c:713 usbnet_probe+0xbe6/0x4390 drivers/net/usb/usbnet.c:1772 CVE-2025-38153 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Abort software beacon handling if disabled A malicious USB device can send a WMI_SWBA_EVENTID event from an ath9k_htc-managed device before beaconing has been enabled. This causes a device-by-zero error in the driver, leading to either a crash or an out of bounds read. Prevent this by aborting the handling in ath9k_htc_swba() if beacons are not enabled. CVE-2025-38157 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction Upon RQ destruction if the firmware command fails which is the last resource to be destroyed some SW resources were already cleaned regardless of the failure. Now properly rollback the object to its original state upon such failure. In order to avoid a use-after free in case someone tries to destroy the object again, which results in the following kernel trace: refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148 Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE) CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : refcount_warn_saturate+0xf4/0x148 lr : refcount_warn_saturate+0xf4/0x148 sp : ffff80008b81b7e0 x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001 x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00 x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000 x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006 x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37f x14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78 x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90 x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fff x5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600 Call trace: refcount_warn_saturate+0xf4/0x148 mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib] mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib] mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib] ib_destroy_wq_user+0x30/0xc0 [ib_core] uverbs_free_wq+0x28/0x58 [ib_uverbs] destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs] uverbs_destroy_uobject+0x48/0x240 [ib_uverbs] __uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs] uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs] ib_uverbs_close+0x2c/0x100 [ib_uverbs] __fput+0xd8/0x2f0 __fput_sync+0x50/0x70 __arm64_sys_close+0x40/0x90 invoke_syscall.constprop.0+0x74/0xd0 do_el0_svc+0x48/0xe8 el0_svc+0x44/0x1d0 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x1a4/0x1a8 CVE-2025-38161 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf: fix ktls panic with sockmap [ 2172.936997] ------------[ cut here ]------------ [ 2172.936999] kernel BUG at lib/iov_iter.c:629! ...... [ 2172.944996] PKRU: 55555554 [ 2172.945155] Call Trace: [ 2172.945299] <TASK> [ 2172.945428] ? die+0x36/0x90 [ 2172.945601] ? do_trap+0xdd/0x100 [ 2172.945795] ? iov_iter_revert+0x178/0x180 [ 2172.946031] ? iov_iter_revert+0x178/0x180 [ 2172.946267] ? do_error_trap+0x7d/0x110 [ 2172.946499] ? iov_iter_revert+0x178/0x180 [ 2172.946736] ? exc_invalid_op+0x50/0x70 [ 2172.946961] ? iov_iter_revert+0x178/0x180 [ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20 [ 2172.947446] ? iov_iter_revert+0x178/0x180 [ 2172.947683] ? iov_iter_revert+0x5c/0x180 [ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840 [ 2172.948206] tls_sw_sendmsg+0x52/0x80 [ 2172.948420] ? inet_sendmsg+0x1f/0x70 [ 2172.948634] __sys_sendto+0x1cd/0x200 [ 2172.948848] ? find_held_lock+0x2b/0x80 [ 2172.949072] ? syscall_trace_enter+0x140/0x270 [ 2172.949330] ? __lock_release.isra.0+0x5e/0x170 [ 2172.949595] ? find_held_lock+0x2b/0x80 [ 2172.949817] ? syscall_trace_enter+0x140/0x270 [ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190 [ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0 [ 2172.951036] __x64_sys_sendto+0x24/0x30 [ 2172.951382] do_syscall_64+0x90/0x170 ...... After calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase, e.g., when the BPF program executes bpf_msg_push_data(). If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes, it will return -ENOSPC and attempt to roll back to the non-zero copy logic. However, during rollback, msg->msg_iter is reset, but since msg_pl->sg.size has been increased, subsequent executions will exceed the actual size of msg_iter. ''' iov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size); ''' The changes in this commit are based on the following considerations: 1. When cork_bytes is set, rolling back to non-zero copy logic is pointless and can directly go to zero-copy logic. 2. We can not calculate the correct number of bytes to revert msg_iter. Assume the original data is "abcdefgh" (8 bytes), and after 3 pushes by the BPF program, it becomes 11-byte data: "abc?de?fgh?". Then, we set cork_bytes to 6, which means the first 6 bytes have been processed, and the remaining 5 bytes "?fgh?" will be cached until the length meets the cork_bytes requirement. However, some data in "?fgh?" is not within 'sg->msg_iter' (but in msg_pl instead), especially the data "?" we pushed. So it doesn't seem as simple as just reverting through an offset of msg_iter. 3. For non-TLS sockets in tcp_bpf_sendmsg, when a "cork" situation occurs, the user-space send() doesn't return an error, and the returned length is the same as the input length parameter, even if some data is cached. Additionally, I saw that the current non-zero-copy logic for handling corking is written as: ''' line 1177 else if (ret != -EAGAIN) { if (ret == -ENOSPC) ret = 0; goto send_end; ''' So it's ok to just return 'copied' without error when a "cork" situation occurs. CVE-2025-38166 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: crypto: marvell/cesa - Handle zero-length skcipher requests Do not access random memory for zero-length skcipher requests. Just return 0. CVE-2025-38173 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Do not double dequeue a configuration request Some of our devices crash in tb_cfg_request_dequeue(): general protection fault, probably for non-canonical address 0xdead000000000122 CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65 RIP: 0010:tb_cfg_request_dequeue+0x2d/0xa0 Call Trace: <TASK> ? tb_cfg_request_dequeue+0x2d/0xa0 tb_cfg_request_work+0x33/0x80 worker_thread+0x386/0x8f0 kthread+0xed/0x110 ret_from_fork+0x38/0x50 ret_from_fork_asm+0x1b/0x30 The circumstances are unclear, however, the theory is that tb_cfg_request_work() can be scheduled twice for a request: first time via frame.callback from ring_work() and second time from tb_cfg_request(). Both times kworkers will execute tb_cfg_request_dequeue(), which results in double list_del() from the ctl->request_queue (the list poison deference hints at it: 0xdead000000000122). Do not dequeue requests that don't have TB_CFG_REQUEST_ACTIVE bit set. CVE-2025-38174 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: atm: fix /proc/net/atm/lec handling /proc/net/atm/lec must ensure safety against dev_lec[] changes. It appears it had dev_put() calls without prior dev_hold(), leading to imbalance and UAF. CVE-2025-38180 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: calipso: Fix null-ptr-deref in calipso_req_{set,del}attr(). syzkaller reported a null-ptr-deref in sock_omalloc() while allocating a CALIPSO option. [0] The NULL is of struct sock, which was fetched by sk_to_full_sk() in calipso_req_setattr(). Since commit a1a5344ddbe8 ("tcp: avoid two atomic ops for syncookies"), reqsk->rsk_listener could be NULL when SYN Cookie is returned to its client, as hinted by the leading SYN Cookie log. Here are 3 options to fix the bug: 1) Return 0 in calipso_req_setattr() 2) Return an error in calipso_req_setattr() 3) Alaways set rsk_listener 1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookie for CALIPSO. 3) is also no go as there have been many efforts to reduce atomic ops and make TCP robust against DDoS. See also commit 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt under synflood"). As of the blamed commit, SYN Cookie already did not need refcounting, and no one has stumbled on the bug for 9 years, so no CALIPSO user will care about SYN Cookie. Let's return an error in calipso_req_setattr() and calipso_req_delattr() in the SYN Cookie case. This can be reproduced by [1] on Fedora and now connect() of nc times out. [0]: TCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_pnet include/net/net_namespace.h:406 [inline] RIP: 0010:sock_net include/net/sock.h:655 [inline] RIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806 Code: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b RSP: 0018:ffff88811af89038 EFLAGS: 00010216 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400 RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030 RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640e R10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000 R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050 FS: 00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0 PKRU: 80000000 Call Trace: <IRQ> ipv6_renew_options+0x279/0x950 net/ipv6/exthdrs.c:1288 calipso_req_setattr+0x181/0x340 net/ipv6/calipso.c:1204 calipso_req_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:597 netlbl_req_setattr+0x18a/0x440 net/netlabel/netlabel_kapi.c:1249 selinux_netlbl_inet_conn_request+0x1fb/0x320 security/selinux/netlabel.c:342 selinux_inet_conn_request+0x1eb/0x2c0 security/selinux/hooks.c:5551 security_inet_conn_request+0x50/0xa0 security/security.c:4945 tcp_v6_route_req+0x22c/0x550 net/ipv6/tcp_ipv6.c:825 tcp_conn_request+0xec8/0x2b70 net/ipv4/tcp_input.c:7275 tcp_v6_conn_request+0x1e3/0x440 net/ipv6/tcp_ipv6.c:1328 tcp_rcv_state_process+0xafa/0x52b0 net/ipv4/tcp_input.c:6781 tcp_v6_do_rcv+0x8a6/0x1a40 net/ipv6/tcp_ipv6.c:1667 tcp_v6_rcv+0x505e/0x5b50 net/ipv6/tcp_ipv6.c:1904 ip6_protocol_deliver_rcu+0x17c/0x1da0 net/ipv6/ip6_input.c:436 ip6_input_finish+0x103/0x180 net/ipv6/ip6_input.c:480 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip6_input+0x13c/0x6b0 net/ipv6/ip6_input.c:491 dst_input include/net/dst.h:469 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] ip6_rcv_finish+0xb6/0x490 net/ipv6/ip6_input.c:69 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netf ---truncated--- CVE-2025-38181 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer The reproduction steps: 1. create a tun interface 2. enable l2 bearer 3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun tipc: Started in network mode tipc: Node identity 8af312d38a21, cluster identity 4711 tipc: Enabled bearer <eth:syz_tun>, priority 1 Oops: general protection fault KASAN: null-ptr-deref in range CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT Hardware name: QEMU Ubuntu 24.04 PC RIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0 the ub was in fact a struct dev. when bid != 0 && skip_cnt != 0, bearer_list[bid] may be NULL or other media when other thread changes it. fix this by checking media_id. CVE-2025-38184 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: atm: atmtcp: Free invalid length skb in atmtcp_c_send(). syzbot reported the splat below. [0] vcc_sendmsg() copies data passed from userspace to skb and passes it to vcc->dev->ops->send(). atmtcp_c_send() accesses skb->data as struct atmtcp_hdr after checking if skb->len is 0, but it's not enough. Also, when skb->len == 0, skb and sk (vcc) were leaked because dev_kfree_skb() is not called and sk_wmem_alloc adjustment is missing to revert atm_account_tx() in vcc_sendmsg(), which is expected to be done in atm_pop_raw(). Let's properly free skb with an invalid length in atmtcp_c_send(). [0]: BUG: KMSAN: uninit-value in atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 vcc_sendmsg+0xd7c/0xff0 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] kmem_cache_alloc_node_noprof+0x818/0xf00 mm/slub.c:4249 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:579 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:670 alloc_skb include/linux/skbuff.h:1336 [inline] vcc_sendmsg+0xb40/0xff0 net/atm/common.c:628 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 1 UID: 0 PID: 5798 Comm: syz-executor192 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(undef) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 CVE-2025-38185 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: atm: Revert atm_account_tx() if copy_from_iter_full() fails. In vcc_sendmsg(), we account skb->truesize to sk->sk_wmem_alloc by atm_account_tx(). It is expected to be reverted by atm_pop_raw() later called by vcc->dev->ops->send(vcc, skb). However, vcc_sendmsg() misses the same revert when copy_from_iter_full() fails, and then we will leak a socket. Let's factorise the revert part as atm_return_tx() and call it in the failure path. Note that the corresponding sk_wmem_alloc operation can be found in alloc_tx() as of the blamed commit. $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~ CVE-2025-38190 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: clear the dst when changing skb protocol A not-so-careful NAT46 BPF program can crash the kernel if it indiscriminately flips ingress packets from v4 to v6: BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10) The output interface has a 4->6 program attached at ingress. We try to loop the multicast skb back to the sending socket. Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdr and changes skb->protocol to v6. We enter ip6_rcv_core which tries to use skb_dst(). But the dst is still an IPv4 one left after IPv4 mcast output. Clear the dst in all BPF helpers which change the protocol. Try to preserve metadata dsts, those may carry non-routing metadata. CVE-2025-38192 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net_sched: sch_sfq: reject invalid perturb period Gerrard Tai reported that SFQ perturb_period has no range check yet, and this can be used to trigger a race condition fixed in a separate patch. We want to make sure ctl->perturb_period * HZ will not overflow and is positive. tc qd add dev lo root sfq perturb -10 # negative value : error Error: sch_sfq: invalid perturb period. tc qd add dev lo root sfq perturb 1000000000 # too big : error Error: sch_sfq: invalid perturb period. tc qd add dev lo root sfq perturb 2000000 # acceptable value tc -s -d qd sh dev lo qdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 CVE-2025-38193 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: fbcon: Make sure modelist not set on unregistered console It looks like attempting to write to the "store_modes" sysfs node will run afoul of unregistered consoles: UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28 index -1 is out of range for type 'fb_info *[32]' ... fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 dev_attr_store+0x55/0x80 drivers/base/core.c:2439 static struct fb_info *fbcon_registered_fb[FB_MAX]; ... static signed char con2fb_map[MAX_NR_CONSOLES]; ... static struct fb_info *fbcon_info_from_console(int console) ... return fbcon_registered_fb[con2fb_map[console]]; If con2fb_map contains a -1 things go wrong here. Instead, return NULL, as callers of fbcon_info_from_console() are trying to compare against existing "info" pointers, so error handling should kick in correctly. CVE-2025-38198 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: i40e: fix MMIO write access to an invalid page in i40e_clear_hw When the device sends a specific input, an integer underflow can occur, leading to MMIO write access to an invalid page. Prevent the integer underflow by changing the type of related variables. CVE-2025-38200 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction The commit 59c68ac31e15 ("iw_cm: free cm_id resources on the last deref") simplified cm_id resource management by freeing cm_id once all references to the cm_id were removed. The references are removed either upon completion of iw_cm event handlers or when the application destroys the cm_id. This commit introduced the use-after-free condition where cm_id_private object could still be in use by event handler works during the destruction of cm_id. The commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs") addressed this use-after- free by flushing all pending works at the cm_id destruction. However, still another use-after-free possibility remained. It happens with the work objects allocated for each cm_id_priv within alloc_work_entries() during cm_id creation, and subsequently freed in dealloc_work_entries() once all references to the cm_id are removed. If the cm_id's last reference is decremented in the event handler work, the work object for the work itself gets removed, and causes the use- after-free BUG below: BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091 CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iw_cm_wq) Call Trace: <TASK> dump_stack_lvl+0x6a/0x90 print_report+0x174/0x554 ? __virt_addr_valid+0x208/0x430 ? __pwq_activate_work+0x1ff/0x250 kasan_report+0xae/0x170 ? __pwq_activate_work+0x1ff/0x250 __pwq_activate_work+0x1ff/0x250 pwq_dec_nr_in_flight+0x8c5/0xfb0 process_one_work+0xc11/0x1460 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x16c/0x240 worker_thread+0x5ef/0xfd0 ? __pfx_worker_thread+0x10/0x10 kthread+0x3b0/0x770 ? __pfx_kthread+0x10/0x10 ? rcu_is_watching+0x11/0xb0 ? _raw_spin_unlock_irq+0x24/0x50 ? rcu_is_watching+0x11/0xb0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 147416: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 alloc_work_entries+0xa9/0x260 [iw_cm] iw_cm_connect+0x23/0x4a0 [iw_cm] rdma_connect_locked+0xbfd/0x1920 [rdma_cm] nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma] cma_cm_event_handler+0xae/0x320 [rdma_cm] cma_work_handler+0x106/0x1b0 [rdma_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 147091: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kfree+0x13a/0x4b0 dealloc_work_entries+0x125/0x1f0 [iw_cm] iwcm_deref_id+0x6f/0xa0 [iw_cm] cm_work_handler+0x136/0x1ba0 [iw_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Last potentially related work creation: kasan_save_stack+0x2c/0x50 kasan_record_aux_stack+0xa3/0xb0 __queue_work+0x2ff/0x1390 queue_work_on+0x67/0xc0 cm_event_handler+0x46a/0x820 [iw_cm] siw_cm_upcall+0x330/0x650 [siw] siw_cm_work_handler+0x6b9/0x2b20 [siw] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 This BUG is reproducible by repeating the blktests test case nvme/061 for the rdma transport and the siw driver. To avoid the use-after-free of cm_id_private work objects, ensure that the last reference to the cm_id is decremented not in the event handler works, but in the cm_id destruction context. For that purpose, mo ---truncated--- CVE-2025-38211 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: ipc: fix to protect IPCS lookups using RCU syzbot reported that it discovered a use-after-free vulnerability, [0] [0]: https://lore.kernel.org/all/67af13f8.050a0220.21dd3.0038.GAE@google.com/ idr_for_each() is protected by rwsem, but this is not enough. If it is not protected by RCU read-critical region, when idr_for_each() calls radix_tree_node_free() through call_rcu() to free the radix_tree_node structure, the node will be freed immediately, and when reading the next node in radix_tree_for_each_slot(), the already freed memory may be read. Therefore, we need to add code to make sure that idr_for_each() is protected within the RCU read-critical region when we call it in shm_destroy_orphaned(). CVE-2025-38212 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2025-38213 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_var If fb_add_videomode() in fb_set_var() fails to allocate memory for fb_videomode, later it may lead to a null-ptr dereference in fb_videomode_to_var(), as the fb_info is registered while not having the mode in modelist that is expected to be there, i.e. the one that is described in fb_info->var. ================================================================ general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901 Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 ================================================================ The reason is that fb_info->var is being modified in fb_set_var(), and then fb_videomode_to_var() is called. If it fails to add the mode to fb_info->modelist, fb_set_var() returns error, but does not restore the old value of fb_info->var. Restore fb_info->var on failure the same way it is done earlier in the function. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. CVE-2025-38214 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: inline: fix len overflow in ext4_prepare_inline_data When running the following code on an ext4 filesystem with inline_data feature enabled, it will lead to the bug below. fd = open("file1", O_RDWR | O_CREAT | O_TRUNC, 0666); ftruncate(fd, 30); pwrite(fd, "a", 1, (1UL << 40) + 5UL); That happens because write_begin will succeed as when ext4_generic_write_inline_data calls ext4_prepare_inline_data, pos + len will be truncated, leading to ext4_prepare_inline_data parameter to be 6 instead of 0x10000000006. Then, later when write_end is called, we hit: BUG_ON(pos + len > EXT4_I(inode)->i_inline_size); at ext4_write_inline_data. Fix it by using a loff_t type for the len parameter in ext4_prepare_inline_data instead of an unsigned int. [ 44.545164] ------------[ cut here ]------------ [ 44.545530] kernel BUG at fs/ext4/inline.c:240! [ 44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full) 112853fcebfdb93254270a7959841d2c6aa2c8bb [ 44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 44.546523] RIP: 0010:ext4_write_inline_data+0xfe/0x100 [ 44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49 [ 44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216 [ 44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006 [ 44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738 [ 44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [ 44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000 [ 44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738 [ 44.546523] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000 [ 44.546523] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0 [ 44.546523] PKRU: 55555554 [ 44.546523] Call Trace: [ 44.546523] <TASK> [ 44.546523] ext4_write_inline_data_end+0x126/0x2d0 [ 44.546523] generic_perform_write+0x17e/0x270 [ 44.546523] ext4_buffered_write_iter+0xc8/0x170 [ 44.546523] vfs_write+0x2be/0x3e0 [ 44.546523] __x64_sys_pwrite64+0x6d/0xc0 [ 44.546523] do_syscall_64+0x6a/0xf0 [ 44.546523] ? __wake_up+0x89/0xb0 [ 44.546523] ? xas_find+0x72/0x1c0 [ 44.546523] ? next_uptodate_folio+0x317/0x330 [ 44.546523] ? set_pte_range+0x1a6/0x270 [ 44.546523] ? filemap_map_pages+0x6ee/0x840 [ 44.546523] ? ext4_setattr+0x2fa/0x750 [ 44.546523] ? do_pte_missing+0x128/0xf70 [ 44.546523] ? security_inode_post_setattr+0x3e/0xd0 [ 44.546523] ? ___pte_offset_map+0x19/0x100 [ 44.546523] ? handle_mm_fault+0x721/0xa10 [ 44.546523] ? do_user_addr_fault+0x197/0x730 [ 44.546523] ? do_syscall_64+0x76/0xf0 [ 44.546523] ? arch_exit_to_user_mode_prepare+0x1e/0x60 [ 44.546523] ? irqentry_exit_to_user_mode+0x79/0x90 [ 44.546523] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 44.546523] RIP: 0033:0x7f42999c6687 [ 44.546523] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff [ 44.546523] RSP: 002b:00007ffeae4a7930 EFLAGS: 00000202 ORIG_RAX: 0000000000000012 [ 44.546523] RAX: ffffffffffffffda RBX: 00007f4299934740 RCX: 00007f42999c6687 [ 44.546523] RDX: 0000000000000001 RSI: 000055ea6149200f RDI: 0000000000000003 [ 44.546523] RBP: 00007ffeae4a79a0 R08: 0000000000000000 R09: 0000000000000000 [ 44.546523] R10: 0000010000000005 R11: 0000000000000202 R12: 0000 ---truncated--- CVE-2025-38222 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister(). syzbot reported a warning below during atm_dev_register(). [0] Before creating a new device and procfs/sysfs for it, atm_dev_register() looks up a duplicated device by __atm_dev_lookup(). These operations are done under atm_dev_mutex. However, when removing a device in atm_dev_deregister(), it releases the mutex just after removing the device from the list that __atm_dev_lookup() iterates over. So, there will be a small race window where the device does not exist on the device list but procfs/sysfs are still not removed, triggering the splat. Let's hold the mutex until procfs/sysfs are removed in atm_dev_deregister(). [0]: proc_dir_entry 'atm/atmtcp:0' already registered WARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377 Modules linked in: CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377 Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 <0f> 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48 RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248 RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001 RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140 R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444 FS: 00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> proc_create_data+0xbe/0x110 fs/proc/generic.c:585 atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361 atm_dev_register+0x46d/0x890 net/atm/resources.c:113 atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369 atmtcp_attach drivers/atm/atmtcp.c:403 [inline] atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x115/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f38b3b74459 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459 RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005 RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0ac R13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b </TASK> CVE-2025-38245 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3() In snd_usb_get_audioformat_uac3(), the length value returned from snd_usb_ctl_msg() is used directly for memory allocation without validation. This length is controlled by the USB device. The allocated buffer is cast to a uac3_cluster_header_descriptor and its fields are accessed without verifying that the buffer is large enough. If the device returns a smaller than expected length, this leads to an out-of-bounds read. Add a length check to ensure the buffer is large enough for uac3_cluster_header_descriptor. CVE-2025-38249 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix use-after-free in vhci_flush() syzbot reported use-after-free in vhci_flush() without repro. [0] From the splat, a thread close()d a vhci file descriptor while its device was being used by iotcl() on another thread. Once the last fd refcnt is released, vhci_release() calls hci_unregister_dev(), hci_free_dev(), and kfree() for struct vhci_data, which is set to hci_dev->dev->driver_data. The problem is that there is no synchronisation after unlinking hdev from hci_dev_list in hci_unregister_dev(). There might be another thread still accessing the hdev which was fetched before the unlink operation. We can use SRCU for such synchronisation. Let's run hci_dev_reset() under SRCU and wait for its completion in hci_unregister_dev(). Another option would be to restore hci_dev->destruct(), which was removed in commit 587ae086f6e4 ("Bluetooth: Remove unused hci-destruct cb"). However, this would not be a good solution, as we should not run hci_unregister_dev() while there are in-flight ioctl() requests, which could lead to another data-race KCSAN splat. Note that other drivers seem to have the same problem, for exmaple, virtbt_remove(). [0]: BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718 CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcf5b98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929 RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009 RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 </TASK> Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/name ---truncated--- CVE-2025-38250 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: bcache: fix NULL pointer in cache_set_flush() 1. LINE#1794 - LINE#1887 is some codes about function of bch_cache_set_alloc(). 2. LINE#2078 - LINE#2142 is some codes about function of register_cache_set(). 3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098. 1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb) 1795 { ... 1860 if (!(c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL)) || 1861 mempool_init_slab_pool(&c->search, 32, bch_search_cache) || 1862 mempool_init_kmalloc_pool(&c->bio_meta, 2, 1863 sizeof(struct bbio) + sizeof(struct bio_vec) * 1864 bucket_pages(c)) || 1865 mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size) || 1866 bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio), 1867 BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) || 1868 !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) || 1869 !(c->moving_gc_wq = alloc_workqueue("bcache_gc", 1870 WQ_MEM_RECLAIM, 0)) || 1871 bch_journal_alloc(c) || 1872 bch_btree_cache_alloc(c) || 1873 bch_open_buckets_alloc(c) || 1874 bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages))) 1875 goto err; ^^^^^^^^ 1876 ... 1883 return c; 1884 err: 1885 bch_cache_set_unregister(c); ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1886 return NULL; 1887 } ... 2078 static const char *register_cache_set(struct cache *ca) 2079 { ... 2098 c = bch_cache_set_alloc(&ca->sb); 2099 if (!c) 2100 return err; ^^^^^^^^^^ ... 2128 ca->set = c; 2129 ca->set->cache[ca->sb.nr_this_dev] = ca; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... 2138 return NULL; 2139 err: 2140 bch_cache_set_unregister(c); 2141 return err; 2142 } (1) If LINE#1860 - LINE#1874 is true, then do 'goto err'(LINE#1875) and call bch_cache_set_unregister()(LINE#1885). (2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return. (3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the value to c->cache[], it means that c->cache[] is NULL. LINE#1624 - LINE#1665 is some codes about function of cache_set_flush(). As (1), in LINE#1885 call bch_cache_set_unregister() ---> bch_cache_set_stop() ---> closure_queue() -.-> cache_set_flush() (as below LINE#1624) 1624 static void cache_set_flush(struct closure *cl) 1625 { ... 1654 for_each_cache(ca, c, i) 1655 if (ca->alloc_thread) ^^ 1656 kthread_stop(ca->alloc_thread); ... 1665 } (4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the kernel crash occurred as below: [ 846.712887] bcache: register_cache() error drbd6: cannot allocate memory [ 846.713242] bcache: register_bcache() error : failed to register device [ 846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered [ 846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8 [ 846.714790] PGD 0 P4D 0 [ 846.715129] Oops: 0000 [#1] SMP PTI [ 846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G OE --------- - - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1 [ 846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018 [ 846.716451] Workqueue: events cache_set_flush [bcache] [ 846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache] [ 846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 <48> 8b b8 f8 09 00 0 ---truncated--- CVE-2025-38263 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: sanitize request list handling Validate the request in nvme_tcp_handle_r2t() to ensure it's not part of any list, otherwise a malicious R2T PDU might inject a loop in request list processing. CVE-2025-38264 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod() In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000, cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's then passed to fb_cvt_hperiod(), where it's used as a divider -- division by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to avoid such overflow... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. CVE-2025-38312 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc: fix double-free on mc_dev The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable. In case the MC device is a DPRC, a new mc_bus is allocated and the mc_dev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed. This commit introduces back the following checkpatch warning which is a false-positive. WARNING: kfree(NULL) is safe and this check is probably not required + if (mc_bus) + kfree(mc_bus); CVE-2025-38313 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced. CVE-2025-38319 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: atm: add lec_mutex syzbot found its way in net/atm/lec.c, and found an error path in lecd_attach() could leave a dangling pointer in dev_lec[]. Add a mutex to protect dev_lecp[] uses from lecd_attach(), lec_vcc_attach() and lec_mcast_attach(). Following patch will use this mutex for /proc/net/atm/lec. BUG: KASAN: slab-use-after-free in lecd_attach net/atm/lec.c:751 [inline] BUG: KASAN: slab-use-after-free in lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008 Read of size 8 at addr ffff88807c7b8e68 by task syz.1.17/6142 CPU: 1 UID: 0 PID: 6142 Comm: syz.1.17 Not tainted 6.16.0-rc1-syzkaller-00239-g08215f5486ec #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xcd/0x680 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 lecd_attach net/atm/lec.c:751 [inline] lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Allocated by task 6132: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4328 [inline] __kvmalloc_node_noprof+0x27b/0x620 mm/slub.c:5015 alloc_netdev_mqs+0xd2/0x1570 net/core/dev.c:11711 lecd_attach net/atm/lec.c:737 [inline] lane_ioctl+0x17db/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 6132: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x51/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2381 [inline] slab_free mm/slub.c:4643 [inline] kfree+0x2b4/0x4d0 mm/slub.c:4842 free_netdev+0x6c5/0x910 net/core/dev.c:11892 lecd_attach net/atm/lec.c:744 [inline] lane_ioctl+0x1ce8/0x23e0 net/atm/lec.c:1008 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x118/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893 CVE-2025-38323 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata() Since handle->h_transaction may be a NULL pointer, so we should change it to call is_handle_aborted(handle) first before dereferencing it. And the following data-race was reported in my fuzzer: ================================================================== BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata write to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1: jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0: jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... value changed: 0x00000000 -> 0x00000001 ================================================================== This issue is caused by missing data-race annotation for jh->b_modified. Therefore, the missing annotation needs to be added. CVE-2025-38337 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/sched: Always pass notifications when child class becomes empty Certain classful qdiscs may invoke their classes' dequeue handler on an enqueue operation. This may unexpectedly empty the child qdisc and thus make an in-flight class passive via qlen_notify(). Most qdiscs do not expect such behaviour at this point in time and may re-activate the class eventually anyways which will lead to a use-after-free. The referenced fix commit attempted to fix this behavior for the HFSC case by moving the backlog accounting around, though this turned out to be incomplete since the parent's parent may run into the issue too. The following reproducer demonstrates this use-after-free: tc qdisc add dev lo root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo parent 1: classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1 tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0 tc qdisc add dev lo parent 2:1 handle 3: netem tc qdisc add dev lo parent 3:1 handle 4: blackhole echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888 tc class delete dev lo classid 1:1 echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888 Since backlog accounting issues leading to a use-after-frees on stale class pointers is a recurring pattern at this point, this patch takes a different approach. Instead of trying to fix the accounting, the patch ensures that qdisc_tree_reduce_backlog always calls qlen_notify when the child qdisc is empty. This solves the problem because deletion of qdiscs always involves a call to qdisc_reset() and / or qdisc_purge_queue() which ultimately resets its qlen to 0 thus causing the following qdisc_tree_reduce_backlog() to report to the parent. Note that this may call qlen_notify on passive classes multiple times. This is not a problem after the recent patch series that made all the classful qdiscs qlen_notify() handlers idempotent. CVE-2025-38350 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del() If an exiting non-autoreaping task has already passed exit_notify() and calls handle_posix_cpu_timers() from IRQ, it can be reaped by its parent or debugger right after unlock_task_sighand(). If a concurrent posix_cpu_timer_del() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cpu_timer_task_rcu() and/or lock_task_sighand() will fail. Add the tsk->exit_state check into run_posix_cpu_timers() to fix this. This fix is not needed if CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y, because exit_task_work() is called before exit_notify(). But the check still makes sense, task_work_add(&tsk->posix_cputimers_work.work) will fail anyway in this case. CVE-2025-38352 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: virtio-net: ensure the received length does not exceed allocated size In xdp_linearize_page, when reading the following buffers from the ring, we forget to check the received length with the true allocate size. This can lead to an out-of-bound read. This commit adds that missing check. CVE-2025-38375 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: ACPICA: Refuse to evaluate a method if arguments are missing As reported in [1], a platform firmware update that increased the number of method parameters and forgot to update a least one of its callers, caused ACPICA to crash due to use-after-free. Since this a result of a clear AML issue that arguably cannot be fixed up by the interpreter (it cannot produce missing data out of thin air), address it by making ACPICA refuse to evaluate a method if the caller attempts to pass fewer arguments than expected to it. CVE-2025-38386 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmodes/displayport: do not index invalid pin_assignments A poorly implemented DisplayPort Alt Mode port partner can indicate that its pin assignment capabilities are greater than the maximum value, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_show will cause a BRK exception due to an out of bounds array access. Prevent for loop in pin_assignment_show from accessing invalid values in pin_assignments by adding DP_PIN_ASSIGN_MAX value in typec_dp.h and using i < DP_PIN_ASSIGN_MAX as a loop condition. CVE-2025-38391 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: Clear the vmci transport packet properly when initializing it In vmci_transport_packet_init memset the vmci_transport_packet before populating the fields to avoid any uninitialised data being left in the structure. CVE-2025-38403 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: Squashfs: check return result of sb_min_blocksize Syzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug. Syzkaller forks multiple processes which after mounting the Squashfs filesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). Now if this ioctl occurs at the same time another process is in the process of mounting a Squashfs filesystem on /dev/loop0, the failure occurs. When this happens the following code in squashfs_fill_super() fails. ---- msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE); msblk->devblksize_log2 = ffz(~msblk->devblksize); ---- sb_min_blocksize() returns 0, which means msblk->devblksize is set to 0. As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2 is set to 64. This subsequently causes the UBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') This commit adds a check for a 0 return by sb_min_blocksize(). CVE-2025-38415 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: do not ping device which has failed to load firmware Syzkaller reports [1, 2] crashes caused by an attempts to ping the device which has failed to load firmware. Since such a device doesn't pass 'ieee80211_register_hw()', an internal workqueue managed by 'ieee80211_queue_work()' is not yet created and an attempt to queue work on it causes null-ptr-deref. [1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff [2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217 CVE-2025-38420 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: perf: Fix sample vs do_exit() Baisheng Gao reported an ARM64 crash, which Mark decoded as being a synchronous external abort -- most likely due to trying to access MMIO in bad ways. The crash further shows perf trying to do a user stack sample while in exit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the address space it is trying to access. It turns out that we stop perf after we tear down the userspace mm; a receipie for disaster, since perf likes to access userspace for various reasons. Flip this order by moving up where we stop perf in do_exit(). Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USER to abort when the current task does not have an mm (exit_mm() makes sure to set current->mm = NULL; before commencing with the actual teardown). Such that CPU wide events don't trip on this same problem. CVE-2025-38424 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfsd: nfsd4_spo_must_allow() must check this is a v4 compound request If the request being processed is not a v4 compound request, then examining the cstate can have undefined results. This patch adds a check that the rpc procedure being executed (rq_procinfo) is the NFSPROC4_COMPOUND procedure. CVE-2025-38430 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/gem: Acquire references on GEM handles for framebuffers A GEM handle can be released while the GEM buffer object is attached to a DRM framebuffer. This leads to the release of the dma-buf backing the buffer object, if any. [1] Trying to use the framebuffer in further mode-setting operations leads to a segmentation fault. Most easily happens with driver that use shadow planes for vmap-ing the dma-buf during a page flip. An example is shown below. [ 156.791968] ------------[ cut here ]------------ [ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430 [...] [ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430 [ 157.043420] Call Trace: [ 157.045898] <TASK> [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0 [ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710 [ 157.065567] ? dma_buf_vmap+0x224/0x430 [ 157.069446] ? __warn.cold+0x58/0xe4 [ 157.073061] ? dma_buf_vmap+0x224/0x430 [ 157.077111] ? report_bug+0x1dd/0x390 [ 157.080842] ? handle_bug+0x5e/0xa0 [ 157.084389] ? exc_invalid_op+0x14/0x50 [ 157.088291] ? asm_exc_invalid_op+0x16/0x20 [ 157.092548] ? dma_buf_vmap+0x224/0x430 [ 157.096663] ? dma_resv_get_singleton+0x6d/0x230 [ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10 [ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10 [ 157.110697] drm_gem_shmem_vmap+0x74/0x710 [ 157.114866] drm_gem_vmap+0xa9/0x1b0 [ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0 [ 157.123086] drm_gem_fb_vmap+0xab/0x300 [ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10 [ 157.133032] ? lockdep_init_map_type+0x19d/0x880 [ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0 [ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180 [ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40 [...] [ 157.346424] ---[ end trace 0000000000000000 ]--- Acquiring GEM handles for the framebuffer's GEM buffer objects prevents this from happening. The framebuffer's cleanup later puts the handle references. Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object instance") triggers the segmentation fault easily by using the dma-buf field more widely. The underlying issue with reference counting has been present before. v2: - acquire the handle instead of the BO (Christian) - fix comment style (Christian) - drop the Fixes tag (Christian) - rename err_ gotos - add missing Link tag CVE-2025-38449 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/sched: Abort __tc_modify_qdisc if parent class does not exist Lion's patch [1] revealed an ancient bug in the qdisc API. Whenever a user creates/modifies a qdisc specifying as a parent another qdisc, the qdisc API will, during grafting, detect that the user is not trying to attach to a class and reject. However grafting is performed after qdisc_create (and thus the qdiscs' init callback) is executed. In qdiscs that eventually call qdisc_tree_reduce_backlog during init or change (such as fq, hhf, choke, etc), an issue arises. For example, executing the following commands: sudo tc qdisc add dev lo root handle a: htb default 2 sudo tc qdisc add dev lo parent a: handle beef fq Qdiscs such as fq, hhf, choke, etc unconditionally invoke qdisc_tree_reduce_backlog() in their control path init() or change() which then causes a failure to find the child class; however, that does not stop the unconditional invocation of the assumed child qdisc's qlen_notify with a null class. All these qdiscs make the assumption that class is non-null. The solution is ensure that qdisc_leaf() which looks up the parent class, and is invoked prior to qdisc_create(), should return failure on not finding the class. In this patch, we leverage qdisc_leaf to return ERR_PTRs whenever the parentid doesn't correspond to a class, so that we can detect it earlier on and abort before qdisc_create is called. [1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/ CVE-2025-38457 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: atm: clip: Fix potential null-ptr-deref in to_atmarpd(). atmarpd is protected by RTNL since commit f3a0592b37b8 ("[ATM]: clip causes unregister hang"). However, it is not enough because to_atmarpd() is called without RTNL, especially clip_neigh_solicit() / neigh_ops->solicit() is unsleepable. Also, there is no RTNL dependency around atmarpd. Let's use a private mutex and RCU to protect access to atmarpd in to_atmarpd(). CVE-2025-38460 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: tipc: Fix use-after-free in tipc_conn_close(). syzbot reported a null-ptr-deref in tipc_conn_close() during netns dismantle. [0] tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and calls tipc_conn_close() for each tipc_conn. The problem is that tipc_conn_close() is called after releasing the IDR lock. At the same time, there might be tipc_conn_recv_work() running and it could call tipc_conn_close() for the same tipc_conn and release its last ->kref. Once we release the IDR lock in tipc_topsrv_stop(), there is no guarantee that the tipc_conn is alive. Let's hold the ref before releasing the lock and put the ref after tipc_conn_close() in tipc_topsrv_stop(). [0]: BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435 CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fc/0x2ef lib/dump_stack.c:118 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasan_report mm/kasan/report.c:412 [inline] __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline] tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 Allocated by task 23: kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 Freed by task 23: __cache_free mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline] kref_put include/linux/kref.h:70 [inline] conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415 The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00) The buggy address belongs to the page: page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0 flags: 0xfff00000000100(slab) raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940 raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb CVE-2025-38464 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: netlink: Fix wraparounds of sk->sk_rmem_alloc. Netlink has this pattern in some places if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) atomic_add(skb->truesize, &sk->sk_rmem_alloc); , which has the same problem fixed by commit 5a465a0da13e ("udp: Fix multiple wraparounds of sk->sk_rmem_alloc."). For example, if we set INT_MAX to SO_RCVBUFFORCE, the condition is always false as the two operands are of int. Then, a single socket can eat as many skb as possible until OOM happens, and we can see multiple wraparounds of sk->sk_rmem_alloc. Let's fix it by using atomic_add_return() and comparing the two variables as unsigned int. Before: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port -1668710080 0 rtnl:nl_wraparound/293 * After: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port 2147483072 0 rtnl:nl_wraparound/290 * ^ `--- INT_MAX - 576 CVE-2025-38465 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtree htb_lookup_leaf has a BUG_ON that can trigger with the following: tc qdisc del dev lo root tc qdisc add dev lo root handle 1: htb default 1 tc class add dev lo parent 1: classid 1:1 htb rate 64bit tc qdisc add dev lo parent 1:1 handle 2: netem tc qdisc add dev lo parent 2:1 handle 3: blackhole ping -I lo -c1 -W0.001 127.0.0.1 The root cause is the following: 1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on the selected leaf qdisc 2. netem_dequeue calls enqueue on the child qdisc 3. blackhole_enqueue drops the packet and returns a value that is not just NET_XMIT_SUCCESS 4. Because of this, netem_dequeue calls qdisc_tree_reduce_backlog, and since qlen is now 0, it calls htb_qlen_notify -> htb_deactivate -> htb_deactiviate_prios -> htb_remove_class_from_row -> htb_safe_rb_erase 5. As this is the only class in the selected hprio rbtree, __rb_change_child in __rb_erase_augmented sets the rb_root pointer to NULL 6. Because blackhole_dequeue returns NULL, netem_dequeue returns NULL, which causes htb_dequeue_tree to call htb_lookup_leaf with the same hprio rbtree, and fail the BUG_ON The function graph for this scenario is shown here: 0) | htb_enqueue() { 0) + 13.635 us | netem_enqueue(); 0) 4.719 us | htb_activate_prios(); 0) # 2249.199 us | } 0) | htb_dequeue() { 0) 2.355 us | htb_lookup_leaf(); 0) | netem_dequeue() { 0) + 11.061 us | blackhole_enqueue(); 0) | qdisc_tree_reduce_backlog() { 0) | qdisc_lookup_rcu() { 0) 1.873 us | qdisc_match_from_root(); 0) 6.292 us | } 0) 1.894 us | htb_search(); 0) | htb_qlen_notify() { 0) 2.655 us | htb_deactivate_prios(); 0) 6.933 us | } 0) + 25.227 us | } 0) 1.983 us | blackhole_dequeue(); 0) + 86.553 us | } 0) # 2932.761 us | qdisc_warn_nonwc(); 0) | htb_lookup_leaf() { 0) | BUG_ON(); ------------------------------------------ The full original bug report can be seen here [1]. We can fix this just by returning NULL instead of the BUG_ON, as htb_dequeue_tree returns NULL when htb_lookup_leaf returns NULL. [1] https://lore.kernel.org/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@willsroot.io/ CVE-2025-38468 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime Assuming the "rx-vlan-filter" feature is enabled on a net device, the 8021q module will automatically add or remove VLAN 0 when the net device is put administratively up or down, respectively. There are a couple of problems with the above scheme. The first problem is a memory leak that can happen if the "rx-vlan-filter" feature is disabled while the device is running: # ip link add bond1 up type bond mode 0 # ethtool -K bond1 rx-vlan-filter off # ip link del dev bond1 When the device is put administratively down the "rx-vlan-filter" feature is disabled, so the 8021q module will not remove VLAN 0 and the memory will be leaked [1]. Another problem that can happen is that the kernel can automatically delete VLAN 0 when the device is put administratively down despite not adding it when the device was put administratively up since during that time the "rx-vlan-filter" feature was disabled. null-ptr-unref or bug_on[2] will be triggered by unregister_vlan_dev() for refcount imbalance if toggling filtering during runtime: $ ip link add bond0 type bond mode 0 $ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q $ ethtool -K bond0 rx-vlan-filter off $ ifconfig bond0 up $ ethtool -K bond0 rx-vlan-filter on $ ifconfig bond0 down $ ip link del vlan0 Root cause is as below: step1: add vlan0 for real_dev, such as bond, team. register_vlan_dev vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1 step2: disable vlan filter feature and enable real_dev step3: change filter from 0 to 1 vlan_device_event vlan_filter_push_vids ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0 step4: real_dev down vlan_device_event vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0 vlan_info_rcu_free //free vlan0 step5: delete vlan0 unregister_vlan_dev BUG_ON(!vlan_info); //vlan_info is null Fix both problems by noting in the VLAN info whether VLAN 0 was automatically added upon NETDEV_UP and based on that decide whether it should be deleted upon NETDEV_DOWN, regardless of the state of the "rx-vlan-filter" feature. [1] unreferenced object 0xffff8880068e3100 (size 256): comm "ip", pid 384, jiffies 4296130254 hex dump (first 32 bytes): 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 81ce31fa): __kmalloc_cache_noprof+0x2b5/0x340 vlan_vid_add+0x434/0x940 vlan_device_event.cold+0x75/0xa8 notifier_call_chain+0xca/0x150 __dev_notify_flags+0xe3/0x250 rtnl_configure_link+0x193/0x260 rtnl_newlink_create+0x383/0x8e0 __rtnl_newlink+0x22c/0xa40 rtnl_newlink+0x627/0xb00 rtnetlink_rcv_msg+0x6fb/0xb70 netlink_rcv_skb+0x11f/0x350 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 ____sys_sendmsg+0x5aa/0x7b0 ___sys_sendmsg+0xfc/0x180 [2] kernel BUG at net/8021q/vlan.c:99! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1)) RSP: 0018:ffff88810badf310 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8 RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80 R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000 R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0 Call Trace: <TASK ---truncated--- CVE-2025-38470 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb() syzbot reported null-ptr-deref in l2cap_sock_resume_cb(). [0] l2cap_sock_resume_cb() has a similar problem that was fixed by commit 1bff51ea59a9 ("Bluetooth: fix use-after-free error in lock_sock_nested()"). Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executed under l2cap_sock_resume_cb(), we can avoid the issue simply by checking if chan->data is NULL. Let's not access to the killed socket in l2cap_sock_resume_cb(). [0]: BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline] BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Workqueue: hci0 hci_rx_work Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_report+0x58/0x84 mm/kasan/report.c:524 kasan_report+0xb0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189 __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37 instrument_atomic_write include/linux/instrumented.h:82 [inline] clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357 hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline] hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514 hci_event_func net/bluetooth/hci_event.c:7511 [inline] hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565 hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070 process_one_work+0x7e8/0x155c kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3321 [inline] worker_thread+0x958/0xed8 kernel/workqueue.c:3402 kthread+0x5fc/0x75c kernel/kthread.c:464 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847 CVE-2025-38473 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: net: sierra: check for no status endpoint The driver checks for having three endpoints and having bulk in and out endpoints, but not that the third endpoint is interrupt input. Rectify the omission. CVE-2025-38474 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_qfq: Fix race condition on qfq_aggregate A race condition can occur when 'agg' is modified in qfq_change_agg (called during qfq_enqueue) while other threads access it concurrently. For example, qfq_dump_class may trigger a NULL dereference, and qfq_delete_class may cause a use-after-free. This patch addresses the issue by: 1. Moved qfq_destroy_class into the critical section. 2. Added sch_tree_lock protection to qfq_dump_class and qfq_dump_class_stats. CVE-2025-38477 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: HID: core: do not bypass hid_hw_raw_request hid_hw_raw_request() is actually useful to ensure the provided buffer and length are valid. Directly calling in the low level transport driver function bypassed those checks and allowed invalid paramto be used. CVE-2025-38494 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: HID: core: ensure the allocated report buffer can contain the reserved report ID When the report ID is not used, the low level transport drivers expect the first byte to be 0. However, currently the allocated buffer not account for that extra byte, meaning that instead of having 8 guaranteed bytes for implement to be working, we only have 7. CVE-2025-38495 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: do_change_type(): refuse to operate on unmounted/not ours mounts Ensure that propagation settings can only be changed for mounts located in the caller's mount namespace. This change aligns permission checking with the rest of mount(2). CVE-2025-38498 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns What we want is to verify there is that clone won't expose something hidden by a mount we wouldn't be able to undo. "Wouldn't be able to undo" may be a result of MNT_LOCKED on a child, but it may also come from lacking admin rights in the userns of the namespace mount belongs to. clone_private_mnt() checks the former, but not the latter. There's a number of rather confusing CAP_SYS_ADMIN checks in various userns during the mount, especially with the new mount API; they serve different purposes and in case of clone_private_mnt() they usually, but not always end up covering the missing check mentioned above. CVE-2025-38499 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: wifi: prevent A-MSDU attacks in mesh networks This patch is a mitigation to prevent the A-MSDU spoofing vulnerability for mesh networks. The initial update to the IEEE 802.11 standard, in response to the FragAttacks, missed this case (CVE-2025-27558). It can be considered a variant of CVE-2020-24588 but for mesh networks. This patch tries to detect if a standard MSDU was turned into an A-MSDU by an adversary. This is done by parsing a received A-MSDU as a standard MSDU, calculating the length of the Mesh Control header, and seeing if the 6 bytes after this header equal the start of an rfc1042 header. If equal, this is a strong indication of an ongoing attack attempt. This defense was tested with mac80211_hwsim against a mesh network that uses an empty Mesh Address Extension field, i.e., when four addresses are used, and when using a 12-byte Mesh Address Extension field, i.e., when six addresses are used. Functionality of normal MSDUs and A-MSDUs was also tested, and confirmed working, when using both an empty and 12-byte Mesh Address Extension field. It was also tested with mac80211_hwsim that A-MSDU attacks in non-mesh networks keep being detected and prevented. Note that the vulnerability being patched, and the defense being implemented, was also discussed in the following paper and in the following IEEE 802.11 presentation: https://papers.mathyvanhoef.com/wisec2025.pdf https://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx CVE-2025-38512 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev() There is a potential NULL pointer dereference in zd_mac_tx_to_dev(). For example, the following is possible: T0 T1 zd_mac_tx_to_dev() /* len == skb_queue_len(q) */ while (len > ZD_MAC_MAX_ACK_WAITERS) { filter_ack() spin_lock_irqsave(&q->lock, flags); /* position == skb_queue_len(q) */ for (i=1; i<position; i++) skb = __skb_dequeue(q) if (mac->type == NL80211_IFTYPE_AP) skb = __skb_dequeue(q); spin_unlock_irqrestore(&q->lock, flags); skb_dequeue() -> NULL Since there is a small gap between checking skb queue length and skb being unconditionally dequeued in zd_mac_tx_to_dev(), skb_dequeue() can return NULL. Then the pointer is passed to zd_mac_tx_status() where it is dereferenced. In order to avoid potential NULL pointer dereference due to situations like above, check if skb is not NULL before passing it to zd_mac_tx_status(). Found by Linux Verification Center (linuxtesting.org) with SVACE. CVE-2025-38513 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/sched: Increment job count before swapping tail spsc queue A small race exists between spsc_queue_push and the run-job worker, in which spsc_queue_push may return not-first while the run-job worker has already idled due to the job count being zero. If this race occurs, job scheduling stops, leading to hangs while waiting on the job's DMA fences. Seal this race by incrementing the job count before appending to the SPSC queue. This race was observed on a drm-tip 6.16-rc1 build with the Xe driver in an SVM test case. CVE-2025-38515 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: atm: clip: Fix memory leak of struct clip_vcc. ioctl(ATMARP_MKIP) allocates struct clip_vcc and set it to vcc->user_back. The code assumes that vcc_destroy_socket() passes NULL skb to vcc->push() when the socket is close()d, and then clip_push() frees clip_vcc. However, ioctl(ATMARPD_CTRL) sets NULL to vcc->push() in atm_init_atmarp(), resulting in memory leak. Let's serialise two ioctl() by lock_sock() and check vcc->push() in atm_init_atmarp() to prevent memleak. CVE-2025-38546 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: HID: core: Harden s32ton() against conversion to 0 bits Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that. Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does. CVE-2025-38556 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 moderate In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping. CVE-2025-38563 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: net/packet: fix a race in packet_set_ring() and packet_notifier() When packet_set_ring() releases po->bind_lock, another thread can run packet_notifier() and process an NETDEV_UP event. This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packet_bind() and packet_notifier()"). There too the packet_notifier NETDEV_UP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken. The po->bind_lock in packet_set_ring and packet_notifier precede the introduction of git history. CVE-2025-38617 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: vsock: Do not allow binding to VMADDR_PORT_ANY It is possible for a vsock to autobind to VMADDR_PORT_ANY. This can cause a use-after-free when a connection is made to the bound socket. The socket returned by accept() also has port VMADDR_PORT_ANY but is not on the list of unbound sockets. Binding it will result in an extra refcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep the binding until socket destruction). Modify the check in __vsock_bind_connectible() to also prevent binding to VMADDR_PORT_ANY. CVE-2025-38618 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: reject TDLS operations when station is not associated syzbot triggered a WARN in ieee80211_tdls_oper() by sending NL80211_TDLS_ENABLE_LINK immediately after NL80211_CMD_CONNECT, before association completed and without prior TDLS setup. This left internal state like sdata->u.mgd.tdls_peer uninitialized, leading to a WARN_ON() in code paths that assumed it was valid. Reject the operation early if not in station mode or not associated. CVE-2025-38644 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:kernel-default-4.12.14-122.272.1 important When using a TarFile.errorlevel = 0 and extracting with a filter the documented behavior is that any filtered members would be skipped and not extracted. However the actual behavior of TarFile.errorlevel = 0 in affected versions is that the member would still be extracted and not skipped. CVE-2025-4435 important There is an issue in CPython when using `bytes.decode("unicode_escape", error="ignore|replace")`. If you are not using the "unicode_escape" encoding or an error handler your usage is not affected. To work-around this issue you may stop using the error= handler and instead wrap the bytes.decode() call in a try-except catching the DecodeError. CVE-2025-4516 moderate Allows arbitrary filesystem writes outside the extraction directory during extraction with filter="data". You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of "data" or "tar". See the tarfile extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter for more information. Note that for Python 3.14 or later the default value of filter= changed from "no filtering" to `"data", so if you are relying on this new default behavior then your usage is also affected. Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links. CVE-2025-4517 important net-tools is a collection of programs that form the base set of the NET-3 networking distribution for the Linux operating system. Inn versions up to and including 2.10, the Linux network utilities (like ifconfig) from the net-tools package do not properly validate the structure of /proc files when showing interfaces. `get_name()` in `interface.c` copies interface labels from `/proc/net/dev` into a fixed 16-byte stack buffer without bounds checking, leading to possible arbitrary code execution or crash. The known attack path does not require privilege but also does not provide privilege escalation in this scenario. A patch is available and expected to be part of version 2.20. CVE-2025-46836 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:net-tools-1.60-765.15.1 moderate There's a vulnerability in the libssh package where when a libssh consumer passes in an unexpectedly large input buffer to ssh_get_fingerprint_hash() function. In such cases the bin_to_base64() function can experience an integer overflow leading to a memory under allocation, when that happens it's possible that the program perform out of bounds write leading to a heap corruption. This issue affects only 32-bits builds of libssh. CVE-2025-4877 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libssh-config-0.9.8-3.18.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libssh4-0.9.8-3.18.1 moderate A vulnerability was found in libssh, where an uninitialized variable exists under certain conditions in the privatekey_from_file() function. This flaw can be triggered if the file specified by the filename doesn't exist and may lead to possible signing failures or heap corruption. CVE-2025-4878 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libssh-config-0.9.8-3.18.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libssh4-0.9.8-3.18.1 moderate ping in iputils before 20250602 allows a denial of service (application error in adaptive ping mode or incorrect data collection) via a crafted ICMP Echo Reply packet, because a zero timestamp can lead to large intermediate values that have an integer overflow when squared during statistics calculations. NOTE: this issue exists because of an incomplete fix for CVE-2025-47268 (that fix was only about timestamp calculations, and it did not account for a specific scenario where the original timestamp in the ICMP payload is zero). CVE-2025-48964 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:iputils-s20161105-11.12.1 moderate A use-after-free vulnerability was found in libxml2. This issue occurs when parsing XPath elements under certain circumstances when the XML schematron has the <sch:name path="..."/> schema elements. This flaw allows a malicious actor to craft a malicious XML document used as input for libxml, resulting in the program's crash using libxml or other possible undefined behaviors. CVE-2025-49794 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libxml2-2-2.9.4-46.90.1 important A vulnerability was found in libxml2. Processing certain sch:name elements from the input XML file can trigger a memory corruption issue. This flaw allows an attacker to craft a malicious XML input file that can lead libxml to crash, resulting in a denial of service or other possible undefined behavior due to sensitive data being corrupted in memory. CVE-2025-49796 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libxml2-2-2.9.4-46.90.1 important urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0. CVE-2025-50181 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:python3-urllib3-1.25.10-3.43.1 moderate A flaw was found in GNU Coreutils. The sort utility's begfield() function is vulnerable to a heap buffer under-read. The program may access memory outside the allocated buffer if a user runs a crafted command using the traditional key format. A malicious input could lead to a crash or leak sensitive data. CVE-2025-5278 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:coreutils-8.25-13.19.1 moderate A flaw was found in the libssh library in versions less than 0.11.2. An out-of-bounds read can be triggered in the sftp_handle function due to an incorrect comparison check that permits the function to access memory beyond the valid handle list and to return an invalid pointer, which is used in further processing. This vulnerability allows an authenticated remote attacker to potentially read unintended memory regions, exposing sensitive information or affect service behavior. CVE-2025-5318 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libssh-config-0.9.8-3.18.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libssh4-0.9.8-3.18.1 moderate A flaw was found in libssh versions built with OpenSSL versions older than 3.0, specifically in the ssh_kdf() function responsible for key derivation. Due to inconsistent interpretation of return values where OpenSSL uses 0 to indicate failure and libssh uses 0 for success-the function may mistakenly return a success status even when key derivation fails. This results in uninitialized cryptographic key buffers being used in subsequent communication, potentially compromising SSH sessions' confidentiality, integrity, and availability. CVE-2025-5372 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libssh-config-0.9.8-3.18.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libssh4-0.9.8-3.18.1 important Vim is an open source, command line text editor. Prior to version 9.1.1552, a path traversal issue in Vim's tar.vim plugin can allow overwriting of arbitrary files when opening specially crafted tar archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1552 contains a patch for the vulnerability. CVE-2025-53905 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:vim-9.1.1629-17.51.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:vim-data-common-9.1.1629-17.51.1 moderate Vim is an open source, command line text editor. Prior to version 9.1.1551, a path traversal issue in Vim's zip.vim plugin can allow overwriting of arbitrary files when opening specially crafted zip archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1551 contains a patch for the vulnerability. CVE-2025-53906 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:vim-9.1.1629-17.51.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:vim-data-common-9.1.1629-17.51.1 moderate Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. In versions 28.2.0 through 28.3.2, when the firewalld service is reloaded it removes all iptables rules including those created by Docker. While Docker should automatically recreate these rules, versions before 28.3.3 fail to recreate the specific rules that block external access to containers. This means that after a firewalld reload, containers with ports published to localhost (like 127.0.0.1:8080) become accessible from remote machines that have network routing to the Docker bridge, even though they should only be accessible from the host itself. The vulnerability only affects explicitly published ports - unpublished ports remain protected. This issue is fixed in version 28.3.3. CVE-2025-54388 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:docker-28.4.0_ce-98.140.1 moderate Vim is an open source, command line text editor. In versions from 9.1.1231 to before 9.1.1400, When processing nested tuples in Vim script, an error during evaluation can trigger a use-after-free in Vim's internal tuple reference management. Specifically, the tuple_unref() function may access already freed memory due to improper lifetime handling, leading to memory corruption. The exploit requires direct user interaction, as the script must be explicitly executed within Vim. This issue has been patched in version 9.1.1400. CVE-2025-55157 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:vim-9.1.1629-17.51.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:vim-data-common-9.1.1629-17.51.1 moderate Vim is an open source, command line text editor. In versions from 9.1.1231 to before 9.1.1406, when processing nested tuples during Vim9 script import operations, an error during evaluation can trigger a double-free in Vim's internal typed value (typval_T) management. Specifically, the clear_tv() function may attempt to free memory that has already been deallocated, due to improper lifetime handling in the handle_import / ex_import code paths. The vulnerability can only be triggered if a user explicitly opens and executes a specially crafted Vim script. This issue has been patched in version 9.1.1406. CVE-2025-55158 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:vim-9.1.1629-17.51.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:vim-data-common-9.1.1629-17.51.1 moderate OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.12 and earlier, when the `AuthType` is set to anything but `Basic`, if the request contains an `Authorization: Basic ...` header, the password is not checked. This results in authentication bypass. Any configuration that allows an `AuthType` that is not `Basic` is affected. Version 2.4.13 fixes the issue. CVE-2025-58060 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:cups-libs-1.7.5-20.54.1 important OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.12 and earlier, an unsafe deserialization and validation of printer attributes causes null dereference in the libcups library. This is a remote DoS vulnerability available in local subnet in default configurations. It can cause the cups & cups-browsed to crash, on all the machines in local network who are listening for printers (so by default for all regular linux machines). On systems where the vulnerability CVE-2024-47176 (cups-filters 1.x/cups-browsed 2.x vulnerability) was not fixed, and the firewall on the machine does not reject incoming communication to IPP port, and the machine is set to be available to public internet, attack vector "Network" is possible. The current versions of CUPS and cups-browsed projects have the attack vector "Adjacent" in their default configurations. Version 2.4.13 contains a patch for CVE-2025-58364. CVE-2025-58364 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:cups-libs-1.7.5-20.54.1 moderate A flaw was found in libxml2's xmlBuildQName function, where integer overflows in buffer size calculations can lead to a stack-based buffer overflow. This issue can result in memory corruption or a denial of service when processing crafted input. CVE-2025-6021 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libxml2-2-2.9.4-46.90.1 important The html.parser.HTMLParser class had worse-case quadratic complexity when processing certain crafted malformed inputs potentially leading to amplified denial-of-service. CVE-2025-6069 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libpython2_7-1_0-2.7.18-33.53.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libpython3_4m1_0-3.4.10-25.158.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:python-2.7.18-33.53.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:python-base-2.7.18-33.53.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:python-xml-2.7.18-33.53.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:python3-base-3.4.10-25.158.1 moderate A flaw was found in the interactive shell of the xmllint command-line tool, used for parsing XML files. When a user inputs an overly long command, the program does not check the input size properly, which can cause it to crash. This issue might allow attackers to run harmful code in rare configurations without modern protections. CVE-2025-6170 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libxml2-2-2.9.4-46.90.1 moderate There exists a vulnerability in SQLite versions before 3.50.2 where the number of aggregate terms could exceed the number of columns available. This could lead to a memory corruption issue. We recommend upgrading to version 3.50.2 or above. CVE-2025-6965 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libsqlite3-0-3.50.2-9.41.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:sqlite3-tcl-3.50.2-9.41.1 important A flaw was found in libxslt where the attribute type, atype, flags are modified in a way that corrupts internal memory management. When XSLT functions, such as the key() process, result in tree fragments, this corruption prevents the proper cleanup of ID attributes. As a result, the system may access freed memory, causing crashes or enabling attackers to trigger heap corruption. CVE-2025-7425 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libxml2-2-2.9.4-46.90.1 important A flaw was found in polkit. When processing an XML policy with 32 or more nested elements in depth, an out-of-bounds write can be triggered. This issue can lead to a crash or other unexpected behavior, and arbitrary code execution is not discarded. To exploit this flaw, a high-privilege account is needed as it's required to place the malicious policy file properly. CVE-2025-7519 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libpolkit0-0.113-5.30.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:polkit-0.113-5.30.1 moderate A flaw was found in libssh, a library that implements the SSH protocol. When calculating the session ID during the key exchange (KEX) process, an allocation failure in cryptographic functions may lead to a NULL pointer dereference. This issue can cause the client or server to crash. CVE-2025-8114 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libssh-config-0.9.8-3.18.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libssh4-0.9.8-3.18.1 moderate There is a defect in the CPython “tarfile” module affecting the “TarFile” extraction and entry enumeration APIs. The tar implementation would process tar archives with negative offsets without error, resulting in an infinite loop and deadlock during the parsing of maliciously crafted tar archives. This vulnerability can be mitigated by including the following patch after importing the “tarfile” module: https://gist.github.com/sethmlarson/1716ac5b82b73dbcbf23ad2eff8b33e1 CVE-2025-8194 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libpython2_7-1_0-2.7.18-33.53.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libpython3_4m1_0-3.4.10-25.158.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:python-2.7.18-33.53.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:python-base-2.7.18-33.53.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:python-xml-2.7.18-33.53.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:python3-3.4.10-25.158.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:python3-base-3.4.10-25.158.1 moderate A flaw was found in libssh's handling of key exchange (KEX) processes when a client repeatedly sends incorrect KEX guesses. The library fails to free memory during these rekey operations, which can gradually exhaust system memory. This issue can lead to crashes on the client side, particularly when using libgcrypt, which impacts application stability and availability. CVE-2025-8277 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libssh-config-0.9.8-3.18.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libssh4-0.9.8-3.18.1 low 1. A cookie is set using the `secure` keyword for `https://target` 2. curl is redirected to or otherwise made to speak with `http://target` (same hostname, but using clear text HTTP) using the same cookie set 3. The same cookie name is set - but with just a slash as path (`path=\"/\",`). Since this site is not secure, the cookie *should* just be ignored. 4. A bug in the path comparison logic makes curl read outside a heap buffer boundary The bug either causes a crash or it potentially makes the comparison come to the wrong conclusion and lets the clear-text site override the contents of the secure cookie, contrary to expectations and depending on the memory contents immediately following the single-byte allocation that holds the path. The presumed and correct behavior would be to plainly ignore the second set of the cookie since it was already set as secure on a secure host so overriding it on an insecure host should not be okay. CVE-2025-9086 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:curl-8.0.1-11.108.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libcurl4-8.0.1-11.108.1 important Issue summary: An application trying to decrypt CMS messages encrypted using password based encryption can trigger an out-of-bounds read and write. Impact summary: This out-of-bounds read may trigger a crash which leads to Denial of Service for an application. The out-of-bounds write can cause a memory corruption which can have various consequences including a Denial of Service or Execution of attacker-supplied code. Although the consequences of a successful exploit of this vulnerability could be severe, the probability that the attacker would be able to perform it is low. Besides, password based (PWRI) encryption support in CMS messages is very rarely used. For that reason the issue was assessed as Moderate severity according to our Security Policy. The FIPS modules in 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue, as the CMS implementation is outside the OpenSSL FIPS module boundary. CVE-2025-9230 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libopenssl1_0_0-1.0.2p-3.98.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:libopenssl1_1-1.1.1d-2.119.1 Public Cloud Image google/sles-12-sp5-v20251010-x86-64:openssl-1_0_0-1.0.2p-3.98.1 moderate