SUSE-IU-2025:2497-1 SUSE Image security@suse.de SUSE Security Team SUSE Image SUSE-IU-2025:2497-1 Interim 1 1 2026-03-19T08:56:58Z current 2025-09-18T01:00:00Z 2025-09-18T01:00:00Z cve-database/bin/generate-cvrf-publiccloud.pl 2021-02-18T01:00:00Z Image update for SUSE-IU-2025:2497-1 / google/sles-15-sp6-chost-byos-v20250918-x86-64 This image update for google/sles-15-sp6-chost-byos-v20250918-x86-64 contains the following changes: Package cpupower was updated: - Show the first 2 lines of kernel-source sources we build against in the package description. Also show the latest git hash commit ID there to be able to track the exact sources the package has been built against. This is essential to be able to determine the exact sources (from kernel-source) the tools are built against. Package curl was updated: - tool_operate: fix return code when --retry is used but not triggered [bsc#1249367] * Add curl-tool_operate-fix-return-code-when-retry-is-used.patch - 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 - Fix the --ftp-pasv option in curl v8.14.1 [bsc#1246197] * tool_getparam: fix --ftp-pasv [5f805ee] * Add curl-fix--ftp-pasv.patch - Update to 8.14.1: [jsc#PED-13055, jsc#PED-13056] * Add _multibuild * Remove patches fixed in the update: - curl-CVE-2024-11053.patch - curl-CVE-2024-2004.patch - curl-CVE-2024-2379.patch - curl-CVE-2024-2398.patch - curl-CVE-2024-2466.patch - curl-CVE-2024-6197.patch - curl-CVE-2024-7264.patch - curl-CVE-2024-8096.patch - curl-CVE-2024-9681.patch - curl-CVE-2025-0167.patch - curl-CVE-2025-0725.patch - curl-aws_sigv4-url-encode-the-canonical-path.patch - curl-mstp-starttls.patch - Sync spec file with SLE codestreams: [jsc#PED-13055, jsc#PED-13056] * Add curl-mini.rpmlintrc to avoid rpmlint shlib-policy-name-error when building the curl-mini package in SLE. * Add libssh minimum version requirements. * Use ldconfig_scriptlets when available. * Remove unused option --disable-ntlm-wb. - Update to 8.14.1: * Security fixes: - [bsc#1243933, CVE-2025-5399] libcurl can possibly get trapped in an endless busy-loop when processing specially crafted packets [d1145df2] * Bugfixes: - asyn-thrdd: fix cleanup when RR fails due to OOM - ftp: fix teardown of DATA connection in done - http: fail early when rewind of input failed when following redirects - multi: fix add_handle resizing - tls BIOs: handle BIO_CTRL_EOF correctly - tool_getparam: make --no-anyauth not be accepted - wolfssl: fix sending of early data - ws: handle blocked sends better - ws: tests and fixes - Update to 8.14.0: * Security fixes: - [CVE-2025-4947, bsc#1243397] QUIC certificate check skip with wolfSSL - [CVE-2025-5025, bsc#1243706] No QUIC certificate pinning with wolfSSL * Changes: - mqtt: send ping at upkeep interval - schannel: handle pkcs12 client certificates containing CA certificates - TLS: add CURLOPT_SSL_SIGNATURE_ALGORITHMS and --sigalgs - vquic: ngtcp2 + openssl support - wcurl: import v2025.04.20 script + docs - websocket: add option to disable auto-pong reply * Bugfixes: - asny-thrdd: fix detach from running thread - async-threaded resolver: use ref counter - async: DoH improvements - build: enable gcc-12/13+, clang-10+ picky warnings - build: enable gcc-15 picky warnings - certs: drop unused `default_bits` from `.prm` files - cf-https-connect: use the passed in dns struct pointer - cf-socket: fix FTP accept connect - cfilters: remove assert - cmake: fix nghttp3 static linking with `USE_OPENSSL_QUIC=ON` - cmake: prefer `COMPILE_OPTIONS` over `CMAKE_C_FLAGS` for custom C options - cmake: revert `CURL_LTO` behavior for multi-config generators - configure: fix --disable-rt - CONTRIBUTE: add project guidelines for AI use - cpool/cshutdown: force close connections under pressure - curl: fix memory leak when -h is used in config file - curl_get_line: handle lines ending on the buffer boundary - headers: enforce a max number of response header to accept - http: fix HTTP/2 handling of TE request header using &quot;trailers&quot; - lib: include files using known path - lib: unify conversions to/from hex - libssh: add NULL check for Curl_meta_get() - libssh: fix memory leak - mqtt: use conn/easy meta hash - multi: do transfer book keeping using mid - multi: init_do(): check result - netrc: avoid NULL deref on weird input - netrc: avoid strdup NULL - netrc: deal with null token better - openssl-quic: avoid potential `-Wnull-dereference`, add assert - openssl-quic: fix shutdown when stream not open - openssl: enable builds for *both* engines and providers - openssl: set the cipher string before doing private cert - progress: avoid integer overflow when gathering total transfer size - rand: update comment on Curl_rand_bytes weak random - rustls: make max size of cert and key reasonable - smb: avoid integer overflow on weird input date - urlapi: redirecting to &quot;&quot; is considered fine * Remove curl-8.13.0-CloseSocket.patch upstream * Rebase libcurl-ocloexec.patch - fix Leap build add curl-8.13.0-CloseSocket.patch - Update to 8.13.0: * Changes: - curl: add write-out variable 'tls_earlydata' - curl: make --url support a file with URLs - gnutls: set priority via --ciphers - IMAP: add CURLOPT_UPLOAD_FLAGS and --upload-flags - lib: add CURLFOLLOW_OBEYCODE and CURLFOLLOW_FIRSTONLY - OpenSSL/quictls: add support for TLSv1.3 early data - rustls: add support for CERTINFO - rustls: add support for SSLKEYLOGFILE - rustls: support ECH w/ DoH lookup for config - rustls: support native platform verifier - var: add a '64dec' function that can base64 decode a string * Bugfixes: - conn: fix connection reuse when SSL is optional - hash: use single linked list for entries - http2: detect session being closed on ingress handling - http2: reset stream on response header error - http: remove a HTTP method size restriction - http: version negotiation - httpsrr: fix port detection - libssh: fix freeing of resources in disconnect - libssh: fix scp large file upload for 32-bit size_t systems - openssl-quic: do not iterate over multi handles - openssl: check return value of X509_get0_pubkey - openssl: drop support for old OpenSSL/LibreSSL versions - openssl: fix crash on missing cert password - openssl: fix pkcs11 URI checking for key files. - openssl: remove bad `goto`s into other scope - setopt: illegal CURLOPT_SOCKS5_AUTH should return error - setopt: setting PROXYUSERPWD after PROXYUSERNAME/PASSWORD is fine - sshserver.pl: adjust `AuthorizedKeysFile2` cutoff version - sshserver: fix excluding obsolete client config lines - SSLCERTS: list support for SSL_CERT_FILE and SSL_CERT_DIR - tftpd: prefix TFTP protocol error `E*` constants with `TFTP_` - tool_operate: fail SSH transfers without server auth - url: call protocol handler's disconnect in Curl_conn_free - urlapi: remove percent encoded dot sequences from the URL path - urldata: remove 'hostname' from struct Curl_async * Rebase patches: - libcurl-ocloexec.patch - curl-secure-getenv.patch - Update to 8.12.1: * Bugfixes: - asyn-thread: fix build with 'CURL_DISABLE_SOCKETPAIR' - asyn-thread: fix HTTPS RR crash - asyn-thread: fix the returned bitmask from Curl_resolver_getsock - asyn-thread: survive a c-ares channel set to NULL - cmake: always reference OpenSSL and ZLIB via imported targets - cmake: respect 'GNUTLS_CFLAGS' when detected via 'pkg-config' - cmake: respect 'GNUTLS_LIBRARY_DIRS' in 'libcurl.pc' and 'curl-config' - content_encoding: #error on too old zlib - imap: TLS upgrade fix - ldap: drop support for legacy Novell LDAP SDK - libssh2: comparison is always true because rc &lt;= -1 - libssh2: raise lowest supported version to 1.2.8 - libssh: drop support for libssh older than 0.9.0 - openssl-quic: ignore ciphers for h3 - pop3: TLS upgrade fix - runtests: fix the disabling of the memory tracking - runtests: quote commands to support paths with spaces - scache: add magic checks - smb: silence '-Warray-bounds' with gcc 13+ - smtp: TLS upgrade fix - tool_cfgable: sort struct fields by size, use bitfields for booleans - tool_getparam: add &quot;TLS required&quot; flag for each such option - vtls: fix multissl-init - wakeup_write: make sure the eventfd write sends eight bytes - Update to 8.12.0: * Security fixes: - [bsc#1234068, CVE-2024-11053] curl could leak the password used for the first host to the followed-to host under certain circumstances. - [bsc#1232528, CVE-2024-9681] HSTS subdomain overwrites parent cache entry - [bsc#1236589, CVE-2025-0665] eventfd double close * Changes: - curl: add byte range support to --variable reading from file - curl: make --etag-save acknowledge --create-dirs - getinfo: fix CURLINFO_QUEUE_TIME_T and add 'time_queue' var - getinfo: provide info which auth was used for HTTP and proxy - hyper: drop support - openssl: add support to use keys and certificates from PKCS#11 provider - QUIC: 0RTT for gnutls via CURLSSLOPT_EARLYDATA - vtls: feature ssls-export for SSL session im-/export * Bugfixes: - altsvc: avoid integer overflow in expire calculation - asyn-ares: acknowledge CURLOPT_DNS_SERVERS set to NULL - asyn-ares: fix memory leak - asyn-ares: initial HTTPS resolve support - asyn-thread: use c-ares to resolve HTTPS RR - async-thread: avoid closing eventfd twice - cd2nroff: do not insist on quoted &lt;&gt; within backticks - cd2nroff: support &quot;none&quot; as a TLS backend - conncache: count shutdowns against host and max limits - content_encoding: drop support for zlib before 1.2.0.4 - content_encoding: namespace GZIP flag constants - content_encoding: put the decomp buffers into the writer structs - content_encoding: support use of custom libzstd memory functions - cookie: cap expire times to 400 days - cookie: parse only the exact expire date - curl: return error if etag options are used with multiple URLs - curl_multi_fdset: include the shutdown connections in the set - curl_sha512_256: rename symbols to the curl namespace - curl_url_set.md: adjust the added-in to 7.62.0 - doh: send HTTPS RR requests for all HTTP(S) transfers - easy: allow connect-only handle reuse with easy_perform - easy: make curl_easy_perform() return error if connection still there - easy_lock: use Sleep(1) for thread yield on old Windows - ECH: update APIs to those agreed with OpenSSL maintainers - GnuTLS: fix 'time_appconnect' for early data - HTTP/2: strip TE request header - http2: fix data_pending check - http2: fix value stored to 'result' is never read - http: ignore invalid Retry-After times - http_aws_sigv4: Fix invalid compare function handling zero-length pairs - https-connect: start next immediately on failure - lib: redirect handling by protocol handler - multi: fix curl_multi_waitfds reporting of fd_count - netrc: 'default' with no credentials is not a match - netrc: fix password-only entries - netrc: restore _netrc fallback logic - ngtcp2: fix memory leak on connect failure - openssl: define `HAVE_KEYLOG_CALLBACK` before use - openssl: fix ECH logic - osslq: use SSL_poll to determine writeability of QUIC streams - sectransp: free certificate on error - select: avoid a NULL deref in cwfds_add_sock - src: omit hugehelp and ca-embed from libcurltool - ssl session cache: change cache dimensions - system.h: add 64-bit curl_off_t definitions for NonStop - telnet: handle single-byte input option - TLS: check connection for SSL use, not handler - tool_formparse.c: make curlx_uztoso a static in here - tool_formparse: accept digits in --form type= strings - tool_getparam: ECH param parsing refix - tool_getparam: fail --hostpubsha256 if libssh2 is not used - tool_getparam: fix &quot;Ignored Return Value&quot; - tool_getparam: fix memory leak on error in parse_ech - tool_getparam: fix the ECH parser - tool_operate: make --etag-compare always accept a non-existing file - transfer: fix CURLOPT_CURLU override logic - urlapi: fix redirect to a new fragment or query (only) - vquic: make vquic_send_packets not return without setting psent - vtls: fix default SSL backend as a fallback - vtls: only remember the expiry timestamp in session cache - websocket: fix message send corruption - x509asn1: add parse recursion limit * Rebase pathes: - libcurl-ocloexec.patch - dont-mess-with-rpmoptflags.patch Package glibc was updated: - regcomp-double-free.patch: posix: Fix double-free after allocation failure in regcomp (CVE-2025-8058, bsc#1246965, BZ #33185) - nscd-gethst-race.patch: Reduce chance of crash when using nscd GETFDHST (bsc#1240058) Package kernel-default was updated: - smb3: move server check earlier when setting channel sequence number (git-fixes). - commit df2adca - ring-buffer: Do not allow events in NMI with generic atomic64 cmpxchg() (git-fixes). - commit 890fc59 - module: Restore the moduleparam prefix length check (git-fixes). - commit ad2fc48 - module: Remove unnecessary +1 from last_unloaded_module::name size (git-fixes). - commit 3efc8ab - audit,module: restore audit logging in load failure case (git-fixes). - kABI: Fix the module::name type in audit_context (git-fixes). - commit 7e23359 - module: Fix memory deallocation on error path in move_module() (git-fixes). - commit bb37d39 - SMB3: rename macro CIFS_SERVER_IS_CHAN to avoid confusion (git-fixes). - Refresh patches.suse/smb-client-fix-use-after-free-of-signing-key.patch. - commit ee8ada8 - smb: client: fix potential deadlock when reconnecting channels (bsc#1246183, CVE-2025-38244). - commit fcf601a - cifs: reconnect helper should set reconnect for the right channel (git-fixes). - commit ae3173e - [SMB3] send channel sequence number in SMB3 requests after reconnects (git-fixes). - commit baa81e9 - net: mana: Add debug logs in MANA network driver (bsc#1246212). - Refresh patches.suse/msft-hv-3280-net-mana-Add-support-for-Multi-Vports-on-Bare-metal.patch. - commit 1b4ad82 - netlink: avoid infinite retry looping in netlink_unicast() (CVE-2025-38465 bsc#1247118). - net: mana: Set tx_packets to post gso processing packet count (bsc#1245731). - net: mana: Allocate MSI-X vectors dynamically (bsc#1245457). - net: mana: Allow irq_setup() to skip cpus for affinity (bsc#1245457). - net: mana: explain irq_setup() algorithm (bsc#1245457). - PCI: hv: Allow dynamic MSI-X vector allocation (bsc#1245457). - PCI/MSI: Export pci_msix_prepare_desc() for dynamic MSI-X allocations (bsc#1245457). - net: mana: Add handler for hardware servicing events (bsc#1245730). - net: mana: Expose additional hardware counters for drop and TC via ethtool (bsc#1245729). - hv_netvsc: Use VF's tso_max_size value when data path is VF (bsc#1246203). - net: mana: Allow tso_max_size to go up-to GSO_MAX_SIZE (bsc#1246203). - commit bdd7f41 - NFS: Fix wakeup of __nfs_lookup_revalidate() in unblock_revalidate() (git-fixes). - commit 80e576f - sched: Add test_and_clear_wake_up_bit() and atomic_dec_and_wake_up() (git-fixes). - commit 3754627 - drm/amdgpu: Add basic validation for RAS header (bsc#1247252 CVE-2025-38426) - commit 5d23e74 - NFS: Fix the setting of capabilities when automounting a new filesystem (git-fixes). - commit fabe208 - sunrpc: fix client side handling of tls alerts (git-fixes). - commit 4c093f3 - NFS: Fixup allocation flags for nfsiod's __GFP_NORETRY (git-fixes). - commit fd58755 - NFSv4.2: another fix for listxattr (git-fixes). - commit 5a2e576 - NFS: Fix filehandle bounds checking in nfs_fh_to_dentry() (git-fixes). - commit 094541e - pNFS/flexfiles: don't attempt pnfs on fatal DS errors (git-fixes). - commit ec1d884 - gpio: mlxbf2: use platform_get_irq_optional() (git-fixes). - ALSA: hda/ca0132: Fix missing error handling in ca0132_alt_select_out() (git-fixes). - ALSA: intel_hdmi: Fix off-by-one error in __hdmi_lpe_audio_probe() (git-fixes). - commit 1750f05 - posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del() (bsc#1246911 CVE-2025-38352). - commit ab7e2c1 - tls: always refresh the queue when reading sock (CVE-2025-38471 bsc#1247450). - ext4: only dirty folios when data journaling regular files (CVE-2025-38220 bsc#1245966). - commit 4468ab0 - net/sched: mqprio: fix stack out-of-bounds write in tc entry parsing (git-fixes). - commit 87e34c3 - net/packet: fix a race in packet_set_ring() and packet_notifier() (git-fixes). - commit caa5d02 - net/sched: taprio: enforce minimum value for picos_per_byte (git-fixes). - commit d33d37f - ipv6: reject malicious packets in ipv6_gso_segment() (git-fixes). - commit e120573 - netpoll: prevent hanging NAPI when netcons gets enabled (git-fixes). - commit d8e3fe4 - tracing/kprobes: Fix to free objects when failed to copy a symbol (git-fixes). - commit a2d3373 - tracing/kprobe: Make trace_kprobe's module callback called after jump_label update (git-fixes). - commit 34ee7ea - kABI fix for net: vlan: fix VLAN 0 refcount imbalance of toggling (CVE-2025-38470 bsc#1247288). - commit 00f8e79 - 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). - idpf: convert control queue mutex to a spinlock (CVE-2025-38392 bsc#1247169). - commit 4f53008 - drm/amd/display: Don't overwrite dce60_clk_mgr (git-fixes). - Revert &quot;vgacon: Add check for vc_origin address range in vgacon_scroll()&quot; (stable-fixes). - commit 6cc69eb - exfat: fdatasync flag should be same like generic_write_sync() (git-fixes). - commit ec3f01f - do_change_type(): refuse to operate on unmounted/not ours mounts (CVE-2025-38498 bsc#1247374) - commit 545afad - vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages() (CVE-2024-56742 bsc#1235613) - commit ff30550 - scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port() (CVE-2025-38399 bsc#1247097). - commit e689eaa - RDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages (git-fixes) - commit 39fb4df - drm/v3d: Disable interrupts before resetting the GPU (CVE-2025-38371 bsc#1247178). - commit 4160ac6 - btrfs: fix log tree replay failure due to file with 0 links and extents (git-fixes). - commit fd0c9dd - 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 b3ac9f0 - Refresh patches.kabi/xsk-Fix-race-condition-in-AF_XDP-generic-RX-path.patch. Drop the static_assert() kABI checks temporarily until we have a proper solution to signal kABI verification. - commit d4817c8 - af_unix: Add a prompt to CONFIG_AF_UNIX_OOB (bsc#1246093). - commit 9dcc611 - net: usbnet: Fix the wrong netif_carrier_on() call (git-fixes). - commit 3ed80f8 - kABI: restore layout of struct msi_desc (CVE-2025-38062 bsc#1245216). - genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie (CVE-2025-38062 bsc#1245216). - commit 19502f4 - Delete patches.suse/af_unix-Disable-MSG_OOB-for-unprivileged-users.patch. - commit e99b1bb - Update config files. (CVE-2025-38236 bsc#1246093) Disable CONFIG_AF_UNIX_OOB as the implementation is ridden with security bugs whose fixes would be hard to backport and the feature has no known users. - commit f8cd607 - Refresh patches.suse/x86-its-Enumerate-Indirect-Target-Selection-ITS-bug.patch. - Refresh patches.suse/x86-its-Add-vmexit-option-to-skip-mitigation-on-some-CPUs.patch. Fix affected model steppings. - commit 115d04b - KVM: x86: Reset IRTE to host control if *new* route isn't postable (bsc#1242960 CVE-2025-37885). - commit b463fcd - enabled CONFIG_X86_INTEL_TSX_MODE_AUTO This is a response to bsc#1246695. As result of TAA vulnerability (CVE-2019-11135) we have aimed to follow the upstream default for TSX but due to a mistake we have ended up using CONFIG_X86_INTEL_TSX_MODE_ON rather than CONFIG_X86_INTEL_TSX_MODE_OFF. This has been noticed later on and fixed to align with upstream. Which has made some users unhappy because they have lost a default TSX functionality even on HW that is not susceptible to CVE-2019-11135. We have discussed different ways to deal with that but the likely most straightforward turned out to be to go with CONFIG_X86_INTEL_TSX_MODE_AUTO which disables TSX only on CVE-2019-11135 affected HW. We are still diverging from the upstream here but there are some positive indications that no new TSX based side channels have been discovered since. - commit 395c9dd - tcp: call tcp_measure_rcv_mss() for ooo packets (git-fixes). - commit 54261d2 - net/sched: sch_qfq: Avoid triggering might_sleep in atomic context in qfq_delete_class (git-fixes). - commit cdfb027 - Refresh patches.suse/af_unix-Disable-MSG_OOB-for-unprivileged-users.patch. Print message upon disabled use. - commit 31d5690 - Refresh patches.suse/virtio-blk-scsi-use-block-layer-helpers-to-calculate.patch. - commit 773f5a0 - Rename to patches.suse/scsi-use-block-layer-helpers-to-calculate-num-of-que.patch. - commit dd839b8 - Refresh patches.suse/nvme-pci-use-block-layer-helpers-to-calculate-num-of.patch. - commit e114e47 - Refresh patches.suse/blk-mq-add-number-of-queue-calc-helper.patch. - commit db4fa45 - Rename to patches.suse/lib-group_cpus-Let-group_cpu_evenly-return-the-numbe.patch. Refresh: - patches.kabi/kabi-fix-group-cpus-evenly.patch - patches.suse/lib-group_cpus-honor-housekeeping-config-when-grouping.patch - commit ca07a82 - btrfs: tests: fix chunk map leak after failure to add it to the tree (git-fixes). - commit 4c3fd9d - lib/group_cpus: fix NULL pointer dereference from group_cpus_evenly() (bsc#1236897). - lib/group_cpus.c: avoid acquiring cpu hotplug lock in group_cpus_evenly (bsc#1236897). - commit 749ceff - btrfs: fix ssd_spread overallocation (git-fixes). - commit 760f402 - btrfs: use btrfs_record_snapshot_destroy() during rmdir (git-fixes). - commit 05219d1 - btrfs: propagate last_unlink_trans earlier when doing a rmdir (git-fixes). - btrfs: rename err to ret in btrfs_rmdir() (git-fixes). - commit 6fea6c3 - btrfs: don't skip remaining extrefs if dir not found during log replay (git-fixes). - commit ae66e11 - btrfs: don't ignore inode missing when replaying log tree (git-fixes). - commit 87671c8 - btrfs: fix inode lookup error handling during log replay (git-fixes). - commit a89d2a6 - nvmet-tcp: fix callback lock for TLS handshake (git-fixes). - nvme: fix misaccounting of nvme-mpath inflight I/O (git-fixes). - nvme: fix endianness of command word prints in nvme_log_err_passthru() (git-fixes). - nvme: fix inconsistent RCU list manipulation in nvme_ns_add_to_ctrl_list() (git-fixes). - commit bbf2481 - RDMA/core: Rate limit GID cache warning messages (git-fixes) - commit fd0e41a - kernel-syms.spec: Drop old rpm release number hack (bsc#1247172). - commit b4fa2d1 - rtc: rv3028: fix incorrect maximum clock rate handling (git-fixes). - rtc: pcf8563: fix incorrect maximum clock rate handling (git-fixes). - rtc: pcf85063: fix incorrect maximum clock rate handling (git-fixes). - rtc: nct3018y: fix incorrect maximum clock rate handling (git-fixes). - rtc: hym8563: fix incorrect maximum clock rate handling (git-fixes). - rtc: ds1307: fix incorrect maximum clock rate handling (git-fixes). - ucount: fix atomic_long_inc_below() argument type (git-fixes). - i3c: fix module_i3c_i2c_driver() with I3C=n (git-fixes). - commit e466472 - pinmux: fix race causing mux_owner NULL with active mux_usecount (git-fixes). - pinctrl: sunxi: Fix memory leak on krealloc failure (git-fixes). - fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-deref (git-fixes). - firewire: ohci: correct code comments about bus_reset tasklet (git-fixes). - commit fd1a6ae - PCI: rockchip-host: Fix &quot;Unexpected Completion&quot; log message (git-fixes). - PCI: endpoint: pci-epf-vntb: Fix the incorrect usage of __iomem attribute (git-fixes). - PCI: endpoint: pci-epf-vntb: Return -ENOENT if pci_epc_get_next_free_bar() fails (git-fixes). - PCI: endpoint: Fix configfs group removal on driver teardown (git-fixes). - PCI: endpoint: Fix configfs group list head handling (git-fixes). - watchdog: ziirave_wdt: check record length in ziirave_firm_verify() (git-fixes). - dmaengine: nbpfaxi: Add missing check after DMA map (git-fixes). - dmaengine: mv_xor: Fix missing check after DMA map and missing unmap (git-fixes). - dmaengine: qcom: gpi: Drop unused gpi_write_reg_field() (git-fixes). - dmaengine: dw-edma: Drop unused dchan2dev() and chan2dev() (git-fixes). - ASoC: fsl_xcvr: get channel status data when PHY is not exists (git-fixes). - soundwire: stream: restore params when prepare ports fail (git-fixes). - power: supply: max14577: Handle NULL pdata when CONFIG_OF is not set (git-fixes). - power: supply: cpcap-charger: Fix null check for power_supply_get_by_name (git-fixes). - ALSA: hda/realtek - Add mute LED support for HP Pavilion 15-eg0xxx (stable-fixes). - can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode (git-fixes). - ALSA: hda: Add missing NVIDIA HDA codec IDs (stable-fixes). - usb: typec: tcpm: apply vbus before data bringup in tcpm_src_attach (git-fixes). - usb: typec: tcpm: allow switching to mode accessory to mux properly (stable-fixes). - usb: typec: tcpm: allow to use sink in accessory mode (stable-fixes). - ALSA: hda/tegra: Add Tegra264 support (stable-fixes). - can: dev: can_restart(): move debug message and stats after successful restart (stable-fixes). - can: dev: can_restart(): reverse logic to remove need for goto (stable-fixes). - commit 0f0c0d9 - btrfs: don't silently ignore unexpected extent type when replaying log (git-fixes). - commit e423498 - btrfs: fix invalid inode pointer dereferences during log replay (git-fixes). - commit 78cbba9 - btrfs: return a btrfs_inode from read_one_inode() (git-fixes). - commit b3a9472 - iommu/arm-smmu-qcom: Add SM6115 MDSS compatible (git-fixes). - iommu/amd: Fix geometry.aperture_end for V2 tables (git-fixes). - commit f8c05a9 - btrfs: return a btrfs_inode from btrfs_iget_logging() (git-fixes). - commit 88ed97b - btrfs: use NOFS context when getting inodes during logging and log replay (git-fixes). - commit 88eb1d5 - virtio-net: ensure the received length does not exceed allocated size (CVE-2025-38375 bsc#1247177). - commit 2adf745 - btrfs: update superblock's device bytes_used when dropping chunk (git-fixes). - commit e33076b - Update patches.suse/0001-mm-hugetlb-fix-huge_pmd_unshare-vs-GUP-fast-race.patch (bsc#1245431 CVE-2025-38085 bsc#1245499). - Update patches.suse/0001-mm-hugetlb-unshare-page-tables-during-VMA-split-not-.patch (bsc#1245431 CVE-2025-38084 bsc#1245498). - Update patches.suse/ACPI-CPPC-Fix-NULL-pointer-dereference-when-nosmp-is.patch (git-fixes CVE-2025-38113 bsc#1245683). - Update patches.suse/ACPICA-Refuse-to-evaluate-a-method-if-arguments-are-.patch (stable-fixes CVE-2025-38386 bsc#1247138). - Update patches.suse/ACPICA-fix-acpi-operand-cache-leak-in-dswstate.c.patch (stable-fixes CVE-2025-38345 bsc#1246337). - Update patches.suse/ACPICA-fix-acpi-parse-and-parseext-cache-leaks.patch (stable-fixes CVE-2025-38344 bsc#1246334). - Update patches.suse/ALSA-usb-audio-Fix-out-of-bounds-read-in-snd_usb_get.patch (git-fixes CVE-2025-38249 bsc#1246171). - Update patches.suse/ASoC-Intel-avs-Verify-content-returned-by-parse_int_.patch (git-fixes CVE-2025-38307 bsc#1246364). - Update patches.suse/ASoC-codecs-wcd9335-Fix-missing-free-of-regulator-su.patch (git-fixes CVE-2025-38259 bsc#1246220). - Update patches.suse/Bluetooth-Fix-NULL-pointer-deference-on-eir_get_serv.patch (git-fixes CVE-2025-38304 bsc#1246240). - Update patches.suse/Bluetooth-Fix-null-ptr-deref-in-l2cap_sock_resume_cb.patch (git-fixes CVE-2025-38473 bsc#1247289). - Update patches.suse/Bluetooth-MGMT-Fix-UAF-on-mgmt_remove_adv_monitor_co.patch (git-fixes CVE-2025-38118 bsc#1245670). - Update patches.suse/HID-core-do-not-bypass-hid_hw_raw_request.patch (stable-fixes CVE-2025-38494 bsc#1247349). - Update patches.suse/HID-core-ensure-the-allocated-report-buffer-can-cont.patch (stable-fixes CVE-2025-38495 bsc#1247348). - Update patches.suse/IB-mlx5-Fix-potential-deadlock-in-MR-deregistration.patch (git-fixes CVE-2025-38373 bsc#1247033). - Update patches.suse/Input-ims-pcu-check-record-size-in-ims_pcu_flash_fir.patch (git-fixes CVE-2025-38428 bsc#1247150). - Update patches.suse/NFC-nci-uart-Set-tty-disc_data-only-in-success-path.patch (git-fixes CVE-2025-38416 bsc#1247151). - Update patches.suse/NFSv4-pNFS-Fix-a-race-to-wake-on-NFS_LAYOUT_DRAIN.patch (git-fixes CVE-2025-38393 bsc#1247170). - Update patches.suse/RDMA-cma-Fix-hang-when-cma_netevent_callback-fails-t.patch (git-fixes CVE-2025-38151 bsc#1245745). - Update patches.suse/RDMA-iwcm-Fix-use-after-free-of-work-objects-after-c.patch (git-fixes CVE-2025-38211 bsc#1246008). - Update patches.suse/RDMA-mlx5-Fix-error-flow-upon-firmware-failure-for-R.patch (git-fixes CVE-2025-38161 bsc#1245777). - Update patches.suse/RDMA-mlx5-Initialize-obj_event-obj_sub_list-before-x.patch (git-fixes CVE-2025-38387 bsc#1247154). - Update patches.suse/Squashfs-check-return-result-of-sb_min_blocksize.patch (git-fixes CVE-2025-38415 bsc#1247147). - Update patches.suse/VMCI-fix-race-between-vmci_host_setup_notify-and-vmc.patch (git-fixes CVE-2025-38102 bsc#1245669). - Update patches.suse/aoe-clean-device-rq_list-in-aoedev_downdev.patch (git-fixes CVE-2025-38326 bsc#1246490). - Update patches.suse/ata-pata_via-Force-PIO-for-ATAPI-devices-on-VT6415-V.patch (stable-fixes CVE-2025-38336 bsc#1246370). - Update patches.suse/backlight-pm8941-Add-NULL-check-in-wled_configure.patch (git-fixes CVE-2025-38143 bsc#1245714). - Update patches.suse/bnxt-properly-flush-XDP-redirect-lists.patch (git-fixes CVE-2025-38246 bsc#1246195). - Update patches.suse/bpf-sockmap-Fix-panic-when-calling-skb_linearize.patch (bsc#1245749 CVE-2025-38154 CVE-2025-38165 bsc#1245757). - Update patches.suse/bus-fsl-mc-fix-double-free-on-mc_dev.patch (git-fixes CVE-2025-38313 bsc#1246342). - Update patches.suse/calipso-Fix-null-ptr-deref-in-calipso_req_-set-del-a.patch (git-fixes CVE-2025-38181 bsc#1246000). - Update patches.suse/comedi-Fail-COMEDI_INSNLIST-ioctl-if-n_insns-is-too-.patch (git-fixes CVE-2025-38481 bsc#1247276). - Update patches.suse/comedi-Fix-initialization-of-data-for-instructions-t.patch (git-fixes CVE-2025-38478 bsc#1247273). - Update patches.suse/comedi-Fix-use-of-uninitialized-data-in-insn_rw_emul.patch (git-fixes CVE-2025-38480 bsc#1247274). - Update patches.suse/comedi-das16m1-Fix-bit-shift-out-of-bounds.patch (git-fixes CVE-2025-38483 bsc#1247278). - Update patches.suse/comedi-das6402-Fix-bit-shift-out-of-bounds.patch (git-fixes CVE-2025-38482 bsc#1247277). - Update patches.suse/crypto-marvell-cesa-Handle-zero-length-skcipher-requ.patch (git-fixes CVE-2025-38173 bsc#1245769). - Update patches.suse/crypto-sun8i-ce-cipher-fix-error-handling-in-sun8i_c.patch (git-fixes CVE-2025-38300 bsc#1246349). - Update patches.suse/dm-bufio-fix-sched-in-atomic-context.patch (git-fixes CVE-2025-38496 bsc#1247284). - Update patches.suse/dma-buf-insert-memory-barrier-before-updating-num_fe.patch (git-fixes CVE-2025-38095 bsc#1245658). - Update patches.suse/dmaengine-idxd-Check-availability-of-workqueue-alloc.patch (stable-fixes CVE-2025-38369 bsc#1247209). - Update patches.suse/dmaengine-ti-Add-NULL-check-in-udma_probe.patch (git-fixes CVE-2025-38138 bsc#1245719). - Update patches.suse/drivers-rapidio-rio_cm.c-prevent-possible-heap-overw.patch (stable-fixes CVE-2025-38090 bsc#1245510). - Update patches.suse/drm-amd-display-Add-null-pointer-check-for-get_first.patch (git-fixes CVE-2025-38362 bsc#1247089). - Update patches.suse/drm-amd-pp-Fix-potential-NULL-pointer-dereference-in.patch (git-fixes CVE-2025-38319 bsc#1246243). - Update patches.suse/drm-exynos-exynos7_drm_decon-add-vblank-check-in-IRQ.patch (git-fixes CVE-2025-38467 bsc#1247146). - Update patches.suse/drm-gem-Acquire-references-on-GEM-handles-for-frameb.patch (stable-fixes CVE-2025-38449 bsc#1247255). - Update patches.suse/drm-i915-gt-Fix-timeline-left-held-on-VMA-alloc-erro.patch (git-fixes CVE-2025-38389 bsc#1247153). - Update patches.suse/drm-msm-Fix-a-fence-leak-in-submit-error-path.patch (stable-fixes CVE-2025-38410 bsc#1247128). - Update patches.suse/drm-msm-Fix-another-leak-in-the-submit-error-path.patch (stable-fixes CVE-2025-38409 bsc#1247285). - Update patches.suse/drm-msm-gpu-Fix-crash-when-throttling-GPU-immediatel.patch (git-fixes CVE-2025-38354 bsc#1247061). - Update patches.suse/drm-scheduler-signal-scheduled-fence-when-kill-job.patch (stable-fixes CVE-2025-38436 bsc#1247227). - Update patches.suse/drm-tegra-Fix-a-possible-null-pointer-dereference.patch (git-fixes CVE-2025-38363 bsc#1247018). - Update patches.suse/fbcon-Make-sure-modelist-not-set-on-unregistered-con.patch (stable-fixes CVE-2025-38198 bsc#1245952). - Update patches.suse/fbdev-Fix-do_register_framebuffer-to-prevent-null-pt.patch (git-fixes CVE-2025-38215 bsc#1246109). - Update patches.suse/fbdev-Fix-fb_set_var-to-prevent-null-ptr-deref-in-fb.patch (git-fixes CVE-2025-38214 bsc#1246042). - Update patches.suse/fbdev-core-fbcvt-avoid-division-by-0-in-fb_cvt_hperi.patch (git-fixes CVE-2025-38312 bsc#1246386). - Update patches.suse/fs-nfs-read-fix-double-unlock-bug-in-nfs_return_empty_folio.patch (git-fixes CVE-2025-38338 bsc#1246258). - Update patches.suse/gve-add-missing-NULL-check-for-gve_alloc_pending_pac.patch (git-fixes CVE-2025-38122 bsc#1245746). - Update patches.suse/hwmon-asus-ec-sensors-check-sensor-index-in-read_str.patch (git-fixes CVE-2025-38142 bsc#1245713). - Update patches.suse/hwmon-ftsteutates-Fix-TOCTOU-race-in-fts_read.patch (git-fixes CVE-2025-38217 bsc#1246002). - Update patches.suse/i2c-designware-Fix-an-initialization-issue.patch (git-fixes CVE-2025-38380 bsc#1247028). - Update patches.suse/i2c-tegra-check-msg-length-in-SMBUS-block-read.patch (bsc#1242086 CVE-2025-38425 bsc#1247251). - Update patches.suse/ice-fix-Tx-scheduler-error-handling-in-XDP-callback.patch (git-fixes CVE-2025-38127 bsc#1245705). - Update patches.suse/iio-accel-fxls8962af-Fix-use-after-free-in-fxls8962a.patch (git-fixes CVE-2025-38485 bsc#1247236). - Update patches.suse/jffs2-check-jffs2_prealloc_raw_node_refs-result-in-few-other-places.patch (git-fixes CVE-2025-38328 bsc#1246249). - Update patches.suse/jffs2-check-that-raw-node-were-preallocated-before-writing-summary.patch (git-fixes CVE-2025-38194 bsc#1245957). - Update patches.suse/media-cxusb-no-longer-judge-rbuf-when-the-write-fail.patch (git-fixes CVE-2025-38229 bsc#1246049). - Update patches.suse/media-imx-jpeg-Cleanup-after-an-allocation-error.patch (git-fixes CVE-2025-38225 bsc#1246041). - Update patches.suse/media-vidtv-Terminating-the-subsequent-process-of-in.patch (git-fixes CVE-2025-38227 bsc#1246031). - Update patches.suse/media-vivid-Change-the-siize-of-the-composing.patch (git-fixes CVE-2025-38226 bsc#1246050). - Update patches.suse/mtd-nand-ecc-mxic-Fix-use-of-uninitialized-variable-.patch (git-fixes CVE-2025-38277 bsc#1246246). - Update patches.suse/mtd-spinand-fix-memory-leak-of-ECC-engine-conf.patch (stable-fixes CVE-2025-38384 bsc#1247035). - Update patches.suse/mtk-sd-Prevent-memory-corruption-from-DMA-map-failur.patch (git-fixes CVE-2025-38401 bsc#1247125). - Update patches.suse/nbd-fix-uaf-in-nbd_genl_connect-error-path.patch (git-fixes CVE-2025-38443 bsc#1247164). - Update patches.suse/net-Fix-TOCTOU-issue-in-sk_is_readable.patch (git-fixes CVE-2025-38112 bsc#1245668). - Update patches.suse/net-fix-udp-gso-skb_segment-after-pull-from-frag_lis.patch (git-fixes CVE-2025-38124 bsc#1245690). - Update patches.suse/net-mdiobus-Fix-potential-out-of-bounds-clause-45-re.patch (git-fixes CVE-2025-38110 bsc#1245665). - Update patches.suse/net-mdiobus-Fix-potential-out-of-bounds-read-write-a.patch (git-fixes CVE-2025-38111 bsc#1245666). - Update patches.suse/net-mlx5-Fix-ECVF-vports-unload-on-shutdown-flow.patch (git-fixes CVE-2025-38109 bsc#1245684). - Update patches.suse/net-phy-clear-phydev-devlink-when-the-link-is-delete.patch (git-fixes CVE-2025-38149 bsc#1245737). - Update patches.suse/net-phy-mscc-Fix-memory-leak-when-using-one-step-tim.patch (git-fixes CVE-2025-38148 bsc#1245735). - Update patches.suse/net-sched-Return-NULL-when-htb_lookup_leaf-encounter.patch (git-fixes CVE-2025-38468 bsc#1247437). - Update patches.suse/net-sched-fix-use-after-free-in-taprio_dev_notifier.patch (git-fixes CVE-2025-38087 bsc#1245504). - Update patches.suse/net-sched-sch_qfq-Fix-race-condition-on-qfq_aggregat.patch (git-fixes CVE-2025-38477 bsc#1247314). - Update patches.suse/net-tipc-fix-refcount-warning-in-tipc_aead_encrypt.patch (CVE-2025-38052 bsc#1244749 CVE-2025-38273 bsc#1246266). - Update patches.suse/net-usb-aqc111-fix-error-handling-of-usbnet-read-cal.patch (git-fixes CVE-2025-38153 bsc#1245744). - Update patches.suse/net-usb-lan78xx-fix-WARN-in-__netif_napi_del_locked-.patch (git-fixes CVE-2025-38385 bsc#1247149). - Update patches.suse/net-wwan-t7xx-Fix-napi-rx-poll-issue.patch (git-fixes CVE-2025-38123 bsc#1245688). - Update patches.suse/net_sched-ets-fix-a-race-in-ets_qdisc_change.patch (git-fixes CVE-2025-38107 bsc#1245676). - Update patches.suse/net_sched-red-fix-a-race-in-__red_change.patch (git-fixes CVE-2025-38108 bsc#1245675). - Update patches.suse/net_sched-sch_sfq-reject-invalid-perturb-period.patch (git-fixes CVE-2025-38193 bsc#1245945). - Update patches.suse/netfilter-nf_set_pipapo_avx2-fix-initial-map-fill.patch (git-fixes CVE-2024-57947 bsc#1236333 CVE-2025-38120 bsc#1245711). - Update patches.suse/nfs-Clean-up-proc-net-rpc-nfs-when-nfs_fs_proc_net_init-fails.patch (git-fixes CVE-2025-38400 bsc#1247123). - Update patches.suse/nfsd-Initialize-ssc-before-laundromat_work-to-prevent-NULL-dereference.patch (git-fixes CVE-2025-38231 bsc#1246055). - Update patches.suse/nfsd-nfsd4_spo_must_allow-must-check-this-is-a-v4-compound-request.patch (git-fixes CVE-2025-38430 bsc#1247160). - Update patches.suse/page_pool-Fix-use-after-free-in-page_pool_recycle_in.patch (git-fixes CVE-2025-38129 bsc#1245723). - Update patches.suse/perf-Fix-sample-vs-do_exit.patch (bsc#1246547 CVE-2025-38424 bsc#1247293). - Update patches.suse/phy-qcom-qmp-usb-Fix-an-NULL-vs-IS_ERR-bug.patch (git-fixes CVE-2025-38275 bsc#1246236). - Update patches.suse/pinctrl-at91-Fix-possible-out-of-boundary-access.patch (git-fixes CVE-2025-38286 bsc#1246283). - Update patches.suse/platform-x86-dell-wmi-sysman-Fix-WMI-data-block-retr.patch (git-fixes CVE-2025-38412 bsc#1247132). - Update patches.suse/platform-x86-dell_rbu-Fix-list-usage.patch (git-fixes CVE-2025-38197 bsc#1246047). - Update patches.suse/powerpc-powernv-memtrace-Fix-out-of-bounds-issue-in-.patch (bsc#1244309 ltc#213790 CVE-2025-38088 bsc#1245506). - Update patches.suse/ptp-remove-ptp-n_vclocks-check-logic-in-ptp_vclock_i.patch (git-fixes CVE-2025-38305 bsc#1246358). - Update patches.suse/regulator-gpio-Fix-the-out-of-bounds-access-to-drvda.patch (git-fixes CVE-2025-38395 bsc#1247171). - Update patches.suse/rose-fix-dangling-neighbour-pointers-in-rose_rt_devi.patch (git-fixes CVE-2025-38377 bsc#1247174). - Update patches.suse/rpl-Fix-use-after-free-in-rpl_do_srh_inline.patch (git-fixes CVE-2025-38476 bsc#1247317). - Update patches.suse/s390-bpf-Fix-bpf_arch_text_poke-with-new_addr-NULL-again.patch (git-fixes bsc#1246870 CVE-2025-38489 bsc#1247241). - Update patches.suse/s390-pkey-Prevent-overflow-in-size-calculation-for-memdup_.patch (git-fixes bsc#1245598 CVE-2025-38257 bsc#1246186). - Update patches.suse/sch_hfsc-make-hfsc_qlen_notify-idempotent.patch (CVE-2025-37798 bsc#1242414 CVE-2025-38177 bsc#1245986). - Update patches.suse/scsi-lpfc-Avoid-potential-ndlp-use-after-free-in-dev.patch (bsc#1242993 CVE-2025-38289 bsc#1246287). - Update patches.suse/scsi-lpfc-Use-memcpy-for-BIOS-version.patch (bsc#1240966 CVE-2025-38332 bsc#1246375). - Update patches.suse/serial-Fix-potential-null-ptr-deref-in-mlb_usio_prob.patch (git-fixes CVE-2025-38135 bsc#1246023). - Update patches.suse/soc-aspeed-Add-NULL-check-in-aspeed_lpc_enable_snoop.patch (git-fixes CVE-2025-38145 bsc#1245765). - Update patches.suse/soc-aspeed-lpc-snoop-Don-t-disable-channels-that-are.patch (git-fixes CVE-2025-38487 bsc#1247238). - Update patches.suse/software-node-Correct-a-OOB-check-in-software_node_g.patch (stable-fixes CVE-2025-38342 bsc#1246453). - Update patches.suse/sunrpc-handle-SVC_GARBAGE-during-svc-auth-processing-as-auth-error.patch (git-fixes CVE-2025-38089 bsc#1245508). - Update patches.suse/thunderbolt-Do-not-double-dequeue-a-configuration-re.patch (stable-fixes CVE-2025-38174 bsc#1245781). - Update patches.suse/usb-chipidea-udc-disconnect-reconnect-from-host-when.patch (git-fixes CVE-2025-38376 bsc#1247176). - Update patches.suse/usb-gadget-u_serial-Fix-race-condition-in-TTY-wakeup.patch (git-fixes CVE-2025-38448 bsc#1247233). - Update patches.suse/usb-net-sierra-check-for-no-status-endpoint.patch (git-fixes CVE-2025-38474 bsc#1247311). - Update patches.suse/usb-renesas_usbhs-Reorder-clock-handling-and-power-m.patch (git-fixes CVE-2025-38136 bsc#1245691). - Update patches.suse/usb-typec-altmodes-displayport-do-not-index-invalid-.patch (git-fixes CVE-2025-38391 bsc#1247181). - Update patches.suse/usb-typec-displayport-Fix-potential-deadlock.patch (git-fixes CVE-2025-38404 bsc#1247271). - Update patches.suse/vgacon-Add-check-for-vc_origin-address-range-in-vgac.patch (git-fixes CVE-2025-38213 bsc#1246037). - Update patches.suse/wifi-ath11k-fix-node-corruption-in-ar-arvifs-list.patch (git-fixes CVE-2025-38293 bsc#1246292). - Update patches.suse/wifi-ath12k-fix-invalid-access-to-memory.patch (git-fixes CVE-2025-38292 bsc#1246295). - Update patches.suse/wifi-ath12k-fix-node-corruption-in-ar-arvifs-list.patch (git-fixes CVE-2025-38290 bsc#1246293). - Update patches.suse/wifi-ath6kl-remove-WARN-on-bad-firmware-input.patch (stable-fixes CVE-2025-38406 bsc#1247210). - Update patches.suse/wifi-ath9k_htc-Abort-software-beacon-handling-if-dis.patch (git-fixes CVE-2025-38157 bsc#1245747). - Update patches.suse/wifi-carl9170-do-not-ping-device-which-has-failed-to.patch (git-fixes CVE-2025-38420 bsc#1247279). - Update patches.suse/wifi-mt76-mt7915-Fix-null-ptr-deref-in-mt7915_mmio_w.patch (git-fixes CVE-2025-38155 bsc#1245748). - Update patches.suse/wifi-mt76-mt7996-drop-fragments-with-multicast-or-br.patch (stable-fixes CVE-2025-38343 bsc#1246438). - Update patches.suse/wifi-p54-prevent-buffer-overflow-in-p54_rx_eeprom_re.patch (git-fixes CVE-2025-38348 bsc#1246262). - Update patches.suse/wifi-rtw88-fix-the-para-buffer-size-to-avoid-reading.patch (git-fixes CVE-2025-38159 bsc#1245751). - commit de345c9 - Revert &quot;cgroup_freezer: cgroup_freezing: Check if not frozen&quot; (bsc#1219338). - sched,freezer: Remove unnecessary warning in __thaw_task (bsc#1219338). - commit 108588a - ipv6: fix possible infinite loop in fib6_info_uses_dev() (git-fixes). - commit 16f1f6e - ipv6: prevent infinite loop in rt6_nlmsg_size() (git-fixes). - commit cb535e8 - net/sched: Restrict conditions for adding duplicating netems to qdisc tree (git-fixes). - commit 6fae648 - Refresh patches.suse/af_unix-Disable-MSG_OOB-for-unprivileged-users.patch. Add cmdline override. - commit 4b6e594 - af_unix: Disable MSG_OOB for unprivileged users (CVE-2025-38236 bsc#1246093). - commit 6110a63 - fs/orangefs: Allow 2 more characters in do_c_string() (git-fixes). - commit 642fa26 - jfs: fix metapage reference count leak in dbAllocCtl (git-fixes). - commit 58c926b - x86/mce/amd: Fix threshold limit reset (git-fixes). - commit 468e2ae - bus: mhi: ep: Update read pointer only after buffer is written (CVE-2025-38429 bsc#1247253). - commit 3341565 - x86/mce: Don't remove sysfs if thresholding sysfs init fails (git-fixes). - commit 3d8385a - x86/mce: Make sure CMCI banks are cleared during shutdown on Intel (git-fixes). - commit fe9eb0f - x86/mce/amd: Add default names for MCA banks and blocks (git-fixes). - commit 27f7700 - x86/traps: Initialize DR6 by writing its architectural reset value (git-fixes). - commit 80ddfd8 - media: venus: vdec: Clamp param smaller than 1fps and bigger than 240 (git-fixes). - commit 1212a93 - x86/cpu/amd: Fix workaround for erratum 1054 (git-fixes). - commit 2d80ddf - mtd: rawnand: atmel: set pmecc data setup time (git-fixes). - mtd: spinand: propagate spinand_wait() errors from spinand_write_page() (git-fixes). - mtd: rawnand: fsmc: Add missing check after DMA map (git-fixes). - mtd: rawnand: rockchip: Add missing check after DMA map (git-fixes). - mtd: rawnand: atmel: Fix dma_mapping_error() address (git-fixes). - mtd: rawnand: renesas: Add missing check after DMA map (git-fixes). - mtd: spi-nor: Fix spi_nor_try_unlock_all() (git-fixes). - mtd: fix possible integer overflow in erase_xfer() (git-fixes). - clk: sunxi-ng: v3s: Fix de clock definition (git-fixes). - clk: clk-axi-clkgen: fix fpfd_max frequency for zynq (git-fixes). - clk: xilinx: vcu: unregister pll_post only if registered correctly (git-fixes). - clk: davinci: Add NULL check in davinci_lpsc_clk_register() (git-fixes). - hwmon: (gsc-hwmon) fix fan pwm setpoint show functions (git-fixes). - pwm: imx-tpm: Reset counter if CMOD is 0 (git-fixes). - media: uvcvideo: Do not mark valid metadata as invalid (git-fixes). - media: ov2659: Fix memory leaks in ov2659_probe() (git-fixes). - media: hi556: correct the test pattern configuration (git-fixes). - media: vivid: fix wrong pixel_array control size (git-fixes). - media: venus: hfi: explicitly release IRQ during teardown (git-fixes). - media: venus: Add a check for packet size after reading from shared memory (git-fixes). - media: venus: protect against spurious interrupts during probe (git-fixes). - media: venus: venc: Clamp param smaller than 1fps and bigger than 240 (git-fixes). - media: v4l2-ctrls: Don't reset handler's error in v4l2_ctrl_handler_free() (git-fixes). - media: v4l2-ctrls: Fix H264 SEPARATE_COLOUR_PLANE check (git-fixes). - media: imx: fix a potential memory leak in imx_media_csc_scaler_device_init() (git-fixes). - media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt() (git-fixes). - media: gspca: Add bounds checking to firmware parser (git-fixes). - media: usbtv: Lock resolution while streaming (git-fixes). - media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format() (git-fixes). - crypto: qat - fix seq_file position update in adf_ring_next() (git-fixes). - crypto: qat - fix DMA direction for compression on GEN2 devices (git-fixes). - crypto: qat - flush misc workqueue during device shutdown (git-fixes). - crypto: qat - disable ZUC-256 capability for QAT GEN5 (git-fixes). - crypto: img-hash - Fix dma_unmap_sg() nents value (git-fixes). - crypto: keembay - Fix dma_unmap_sg() nents value (git-fixes). - hwrng: mtk - handle devm_pm_runtime_enable errors (git-fixes). - crypto: ccp - Fix crash when rebind ccp device for ccp.ko (git-fixes). - crypto: inside-secure - Fix `dma_unmap_sg()` nents value (git-fixes). - crypto: ccp - Fix locking on alloc failure handling (git-fixes). - crypto: arm/aes-neonbs - work around gcc-15 warning (git-fixes). - crypto: qat - fix state restore for banks with exceptions (git-fixes). - crypto: qat - allow enabling VFs in the absence of IOMMU (git-fixes). - crypto: marvell/cesa - Fix engine load inaccuracy (git-fixes). - crypto: qat - use unmanaged allocation for dc_data (git-fixes). - crypto: sun8i-ce - fix nents passed to dma_unmap_sg() (git-fixes). - commit 8f3fb2a - Move upstreamed SCSI and ACPI patches into sorted section - commit 09d9d7c - RDMA/uverbs: Add empty rdma_uattrs_has_raw_cap() declaration (git-fixes) - commit ced3c6d - Update config files. run_oldconfig, no functional change. - commit 0b6044b - RDMA/mlx5: Fix compilation warning when USER_ACCESS isn't set (git-fixes) - commit dce79bd - RDMA/hns: Fix -Wframe-larger-than issue (git-fixes) - commit 90a067b - RDMA/hns: Drop GFP_NOWARN (git-fixes) - commit 927f6d6 - RDMA/hns: Fix accessing uninitialized resources (git-fixes) - commit c1be2f8 - RDMA/hns: Get message length of ack_req from FW (git-fixes) - commit 2e9a431 - RDMA/hns: Fix HW configurations not cleared in error flow (git-fixes) - commit ba6e757 - RDMA/hns: Fix double destruction of rsv_qp (git-fixes) - commit 0d7fee3 - Fix dma_unmap_sg() nents value (git-fixes) - commit 89d1cb0 - RDMA/counter: Check CAP_NET_RAW check in user namespace for RDMA counters (git-fixes) - commit c5238e7 - RDMA/nldev: Check CAP_NET_RAW in user namespace for QP modify (git-fixes) - commit 0d7ab5b - RDMA/mlx5: Check CAP_NET_RAW in user namespace for devx create (git-fixes) - commit c162c8c - RDMA/uverbs: Check CAP_NET_RAW in user namespace for RAW QP create (git-fixes) - commit 3292115 - RDMA/uverbs: Check CAP_NET_RAW in user namespace for QP create (git-fixes) - commit 90f88d3 - RDMA/mlx5: Check CAP_NET_RAW in user namespace for anchor create (git-fixes) - commit a812e80 - RDMA/mlx5: Check CAP_NET_RAW in user namespace for flow create (git-fixes) - commit 9dcd5e1 - RDMA/uverbs: Check CAP_NET_RAW in user namespace for flow create (git-fixes) - commit eaff4b0 - vsock: Fix transport_{g2h,h2g} TOCTOU (CVE-2025-38462 bsc#1247104). - commit f5da768 - tcp: Correct signedness in skb remaining space calculation (CVE-2025-38463 bsc#1247113). - net/sched: Always pass notifications when child class becomes empty (CVE-2025-38350 bsc#1246781). - maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate() (CVE-2025-38364 bsc#1247091). - commit 7390872 - x86: UV RTC: Add parameter to disable RTC clocksource (bsc#1241345). - commit 79ccdce - clocksource: Set cs_watchdog_read() checks based on .uncertainty_margin (bsc#1241345 bsc#1244457). - commit 09911af - clocksource: Scale the watchdog read retries automatically (bsc#1241345 bsc#1244457). - Refresh patches.suse/clocksource-Fix-brown-bag-boolean-thinko-in-cs_watch.patch. - Refresh patches.suse/clocksource-Make-watchdog-and-suspend-timing-multipl.patch. - commit fdf040b - wifi: iwlwifi: Fix error code in iwl_op_mode_dvm_start() (git-fixes). - wifi: iwlwifi: return ERR_PTR from opmode start() (stable-fixes). - commit bb4c593 - drm/amd/pm/powerplay/hwmgr/smu_helper: fix order of mask and value (git-fixes). - fbcon: Fix outdated registered_fb reference in comment (git-fixes). - drm/msm/dpu: Fill in min_prefill_lines for SC8180X (git-fixes). - drm/vmwgfx: Fix Host-Backed userspace on Guest-Backed kernel (git-fixes). - drm/panfrost: Fix panfrost device variable name in devfreq (git-fixes). - drm/rockchip: cleanup fb when drm_gem_fb_afbc_init failed (git-fixes). - can: peak_usb: fix USB FD devices potential malfunction (git-fixes). - net: phy: micrel: fix KSZ8081/KSZ8091 cable test (git-fixes). - net: usbnet: Avoid potential RCU stall on LINK_CHANGE event (git-fixes). - can: kvaser_usb: Assign netdev.dev_port based on device channel index (git-fixes). - can: kvaser_pciefd: Store device channel index (git-fixes). - Bluetooth: hci_event: Mask data status from LE ext adv reports (git-fixes). - wifi: ath12k: fix endianness handling while accessing wmi service bit (git-fixes). - wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask() (git-fixes). - wifi: ath12k: fix dest ring-buffer corruption when ring is full (git-fixes). - wifi: ath12k: fix source ring-buffer corruption (git-fixes). - wifi: ath12k: fix dest ring-buffer corruption (git-fixes). - wifi: ath11k: fix dest ring-buffer corruption when ring is full (git-fixes). - wifi: ath11k: fix source ring-buffer corruption (git-fixes). - wifi: ath11k: fix dest ring-buffer corruption (git-fixes). - wifi: ath11k: fix suspend use-after-free after probe failure (git-fixes). - wifi: ath11k: clear initialized flag for deinit-ed srng lists (git-fixes). - wifi: brcmfmac: fix P2P discovery failure in P2P peer due to missing P2P IE (git-fixes). - Reapply &quot;wifi: mac80211: Update skb's control block key in ieee80211_tx_dequeue()&quot; (git-fixes). - wifi: mac80211: Check 802.11 encaps offloading in ieee80211_tx_h_select_key() (git-fixes). - wifi: mac80211: Don't call fq_flow_idx() for management frames (git-fixes). - wifi: mac80211: Do not schedule stopped TXQs (git-fixes). - wifi: plfxlc: Fix error handling in usb driver probe (git-fixes). - wifi: mac80211: reject TDLS operations when station is not associated (git-fixes). - wifi: brcmsmac: Remove const from tbl_ptr parameter in wlc_lcnphy_common_read_table() (git-fixes). - mwl8k: Add missing check after DMA map (git-fixes). - iwlwifi: Add missing check for alloc_ordered_workqueue (git-fixes). - wifi: iwlwifi: Fix memory leak in iwl_mvm_init() (git-fixes). - wifi: rtl818x: Kill URBs before clearing tx status queue (git-fixes). - wifi: rtw89: avoid NULL dereference when RX problematic packet on unsupported 6 GHz band (git-fixes). - commit 338f129 - usb: gadget: configfs: Fix OOB read on empty string write (CVE-2025-38497 bsc#1247347). - commit 96c22e3 - fs: export anon_inode_make_secure_inode() and fix secretmem LSM bypass (CVE-2025-38396 bsc#1247156). - commit 281f5f1 - wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850 (CVE-2025-38414 bsc#1247145). - commit be37365 - Docs/ABI: Fix sysfs-kernel-address_bits path (git-fixes). - soc: qcom: pmic_glink: fix OF node leak (git-fixes). - soc: qcom: fix endianness for QMI header (git-fixes). - soc: qcom: QMI encoding/decoding for big endian (git-fixes). - soc/tegra: cbb: Clear ERR_FORCE register with ERR_STATUS (git-fixes). - usb: musb: omap2430: fix device leak at unbind (git-fixes). - usb: gadget: udc: renesas_usb3: fix device leak at unbind (git-fixes). - usb: dwc3: meson-g12a: fix device leaks at unbind (git-fixes). - usb: atm: cxacru: Merge cxacru_upload_firmware() into cxacru_heavy_init() (git-fixes). - thunderbolt: Fix copy+paste error in match_service_id() (git-fixes). - usb: typec: ucsi: Update power_supply on power role change (git-fixes). - usb: gadget : fix use-after-free in composite_dev_cleanup() (git-fixes). - cdc-acm: fix race between initial clearing halt and open (git-fixes). - usb: early: xhci-dbc: Fix early_ioremap leak (git-fixes). - usb: misc: apple-mfi-fastcharge: Make power supply names unique (git-fixes). - Documentation: usb: gadget: Wrap remaining usage snippets in literal code block (git-fixes). - usb: host: xhci-plat: fix incorrect type for of_match variable in xhci_plat_probe() (git-fixes). - vt: defkeymap: Map keycodes above 127 to K_HOLE (git-fixes). - vt: keyboard: Don't process Unicode characters in K_OFF mode (git-fixes). - staging: axis-fifo: remove sysfs interface (git-fixes). - staging: nvec: Fix incorrect null termination of battery manufacturer (git-fixes). - staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc() (git-fixes). - iio: adc: ad_sigma_delta: change to buffer predisable (git-fixes). - iio: imu: bno055: fix OOB access of hw_xlate array (git-fixes). - bus: mhi: host: Detect events pointing to unexpected TREs (git-fixes). - misc: rtsx: usb: Ensure mmc child device is active when card is present (git-fixes). - vmci: Prevent the dispatching of uninitialized payloads (git-fixes). - samples: mei: Fix building on musl libc (git-fixes). - platform/chrome: cros_ec: Unregister notifier in cros_ec_unregister() (git-fixes). - gpio: virtio: Fix config space reading (git-fixes). - ASoC: ops: dynamically allocate struct snd_ctl_elem_value (git-fixes). - ASoC: soc-dai: tidyup return value of snd_soc_xlate_tdm_slot_mask() (git-fixes). - Documentation: ACPI: Fix parent device references (git-fixes). - ACPI: LPSS: Remove AudioDSP related ID (git-fixes). - ACPI: processor: perflib: Fix initial _PPC limit application (git-fixes). - powercap: dtpm_cpu: Fix NULL pointer dereference in get_pd_power_uw() (git-fixes). - PM / devfreq: Check governor before using governor-&gt;name (git-fixes). - commit fbd21ae - apple-mfi-fastcharge: protect first device name (git-fixes). - commit 903dc58 - vsock/vmci: Clear the vmci transport packet properly when initializing it (CVE-2025-38403 bsc#1247141). - commit 6379963 - KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight (CVE-2025-38455 bsc#1247101). - commit ca76701 - vsock: Fix transport_* TOCTOU (CVE-2025-38461 bsc#1247103). - commit 916fdd6 - eventpoll: don't decrement ep refcount while still holding the ep mutex (bsc#1246777 CVE-2025-38349). - commit 6c5e857 - jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata() (bsc#1246253 CVE-2025-38337). - commit 4cfb834 - ext4: inline: fix len overflow in ext4_prepare_inline_data (bsc#1245976 CVE-2025-38222). - commit bdddb2f - ublk: santizize the arguments from userspace when adding a device (bsc#1245937 CVE-2025-38182). - commit c70260e - __legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock (bsc#1245151 CVE-2025-38058). - commit 5d79b46 - xfs: remove unused trace event xfs_reflink_cow_enospc (git-fixes). - commit 43f2e3c - xfs: only create event xfs_file_compat_ioctl when CONFIG_COMPAT is configure (git-fixes). - commit 90cf0ff - xfs: remove usused xfs_end_io_direct events (git-fixes). - commit 973d0e0 - xfs: remove unused event xfs_pagecache_inval (git-fixes). - commit 92f5436 - xfs: remove unused event xfs_alloc_near_nominleft (git-fixes). - commit cce777b - xfs: remove unused event xfs_alloc_near_error (git-fixes). - commit 5b572bf - xfs: remove unused event xfs_attr_node_removename (git-fixes). - commit 4753b23 - xfs: remove unused xfs_attr events (git-fixes). - commit 1b0cc0c - xfs: remove unused trace event xfs_attr_rmtval_set (git-fixes). - commit d855e56 - xfs: remove unused xfs_reflink_compare_extents events (git-fixes). - commit a7afc4b - xfs: remove unused event xfs_ioctl_clone (git-fixes). - commit b5dfc1b - xfs: remove unused event xlog_iclog_want_sync (git-fixes). - commit 217c9f9 - xfs: remove unused trace event xfs_attr_remove_iter_return (git-fixes). - commit 70b1bc5 - NFSD: detect mismatch of file handle and delegation stateid in OPEN op (git-fixes). - commit 00b51c6 - nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm() (git-fixes). - commit b0cf612 - hfsplus: remove mutex_lock check in hfsplus_free_extents (git-fixes). - commit e14f374 - s390/entry: Fix last breaking event handling in case of stack corruption (git-fixes bsc#1243806). - commit d31e65a - hfs: make splice write available again (git-fixes). - commit 96498bf - hfsplus: make splice write available again (git-fixes). - commit 5121068 - Refresh patches.suse/btrfs-always-fallback-to-buffered-write-if-the-inode.patch. To remove an incorrectly generated file which is not utilized at all. - commit 8e57a15 - btrfs: fix non-empty delayed iputs list on unmount due to async workers (git-fixes). - commit 285c1f5 - btrfs: fix assertion when building free space tree (git-fixes). - commit a3fd65f - btrfs: fix iteration of extrefs during log replay (bsc#1247031 CVE-2025-38382). - commit 5e64fe6 - btrfs: fix missing error handling when searching for inode refs during log replay (git-fixes). - commit a8205e6 - i2c: qup: jump out of the loop in case of timeout (git-fixes). - i2c: virtio: Avoid hang by using interruptible completion wait (git-fixes). - i2c: tegra: Fix reset error handling with ACPI (git-fixes). - commit 5a2e6c7 - btrfs: fix a race between renames and directory logging (bsc#1247023 CVE-2025-38365). - commit 322c28e - supported.conf: move nvme-apple to optional again - commit a3e3a0c - llist: add interface to check if a node is on a list (CVE-2025-38264 bsc#1246387). - commit f06e99c - nvme-tcp: sanitize request list handling (CVE-2025-38264 bsc#1246387). - commit 33933f9 - supported.conf: sort entries again - commit 2db834f - supported.conf: add missing entries for armv7hl - commit 3fcf489 - nilfs2: reject invalid file types when reading inodes (git-fixes). - commit b094111 - resource: fix false warning in __request_region() (git-fixes). - bus: fsl-mc: Fix potential double device reference in fsl_mc_get_endpoint() (git-fixes). - USB: serial: option: add Telit Cinterion FE910C04 (ECM) composition (stable-fixes). - USB: serial: ftdi_sio: add support for NDI EMGUIDE GEMINI (stable-fixes). - USB: serial: option: add Foxconn T99W640 (stable-fixes). - iio: adc: max1363: Reorder mode_list[] entries (stable-fixes). - iio: adc: max1363: Fix MAX1363_4X_CHANS/MAX1363_8X_CHANS[] (stable-fixes). - ALSA: hda/realtek: Add quirk for ASUS ROG Strix G712LWS (stable-fixes). - HID: core: do not bypass hid_hw_raw_request (stable-fixes). - HID: core: ensure the allocated report buffer can contain the reserved report ID (stable-fixes). - regulator: pwm-regulator: Calculate the output voltage for disabled PWMs (stable-fixes). - commit 829a426 - 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 - iommu/vt-d: Fix possible circular locking dependency (git-fixes). - commit 0774c7d - drm/bridge: ti-sn65dsi86: Remove extra semicolon in ti_sn_bridge_probe() (git-fixes). - drm/sched: Remove optimization that causes hang when killing dependent jobs (git-fixes). - platform/x86: ideapad-laptop: Fix kbd backlight not remembered among boots (git-fixes). - commit 0083a37 - iommu/vt-d: Fix system hang on reboot -f (git-fixes). - commit 034e69f - 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). - commit 1698a7c - KVM: x86: Load DR6 with guest value only before entering .vcpu_run() loop (bsc#1239061 CVE-2025-21839). - commit fe1f630 - net: dsa: b53: do not enable EEE on bcm63xx (CVE-2025-38272 bsc#1246268). - commit ee16b59 - Refresh patches.suse/selftests-bpf-Clean-up-open-coded-gettid-syscall-inv.patch. Fix following BPF selftests compilation error due to missing dependency. /home/runner/work/libbpf/libbpf/.kernel/tools/testing/selftests/bpf/prog_tests/ns_current_pid_tgid.c: In function ‘test_current_pid_tgid’: /home/runner/work/libbpf/libbpf/.kernel/tools/testing/selftests/bpf/prog_tests/ns_current_pid_tgid.c:31:9: error: invalid type argument of unary ‘*’ (have ‘pid_t’ {aka ‘int’}) 31 | *pid = sys_gettid(); | ^~~~ - commit d85d5ff - Delete patches.suse/selftests-bpf-Add-tests-for-sdiv-smod-overflow-cases.patch. The __arch_x86_64 macro is not yet supported in BPF selftests (depends on c64d2f72bf2e &quot;selftests/bpf: *_arch** macro to limit test cases to specific archs&quot;), so drop tests that uses it. - commit 55e800e - Bluetooth: hci_sync: Fix UAF on create_le_conn_complete (git-fixes). - commit 7a089da - hci_dev centralize extra lock (CVE-2025-38117 bsc#1245695). - commit 892de21 - Bluetooth: MGMT: Protect mgmt_pending list with its own lock (CVE-2025-38117 bsc#1245695). - commit e0d8b29 - Bluetooth: hci_sync: Introduce hci_cmd_sync_run/hci_cmd_sync_run_once (CVE-2025-38117 bsc#1245695). - commit c86dd9a - Bluetooth: hci_core: Make hci_is_le_conn_scanning public (CVE-2025-38117 bsc#1245695). - Refresh patches.suse/Bluetooth-hci_sync-Use-QoS-to-determine-which-PHY-to.patch. - commit 566b348 - Bluetooth: hci_sync: Fix handling of HCI_OP_CREATE_CONN_CANCEL (git-fixes). - commit 79fc3de - gpiolib: of: Add polarity quirk for s5m8767 (stable-fixes). - gpio: vf610: add locking to gpio direction functions (git-fixes). - gpio: pca953x: log an error when failing to get the reset GPIO (git-fixes). - gpiolib: cdev: Ignore reconfiguration without direction (git-fixes). - gpiolib: acpi: Fix failed in acpi_gpiochip_find() by adding parent node match (bsc#1233300). - gpiolib: Fix debug messaging in gpiod_find_and_request() (git-fixes). - gpiolib: Handle no pin_ranges in gpiochip_generic_config() (git-fixes). - gpio: sim: include a missing header (git-fixes). - gpiolib: acpi: Don't use GPIO chip fwnode in acpi_gpiochip_find() (bsc#1233300). - commit 75afc01 - Bluetooth: MGMT: convert timeouts to secs_to_jiffies() (CVE-2025-38117 bsc#1245695). - commit 3e2758a - bluetooth: mgmt: convert timeouts to secs_to_jiffies() (CVE-2025-38117 bsc#1245695). - commit b8976eb - s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again (git-fixes bsc#1246870). - commit 8e4fb25 - Fix build warning Refresh patches.suse/mm-hugetlb-fix-DEBUG_LOCKS_WARN_ON-1-when-dissolve_f.patch. - commit ccb6e90 - Bluetooth: MGMT: Fix not generating command complete for MGMT_OP_DISCONNECT (git-fixes). - Refresh patches.suse/Bluetooth-hci_event-Fix-not-using-key-encryption-siz.patch. - commit 6f743e7 - Bluetooth: hci_sync: Attempt to dequeue connection attempt (git-fixes). - Refresh patches.suse/Bluetooth-L2CAP-Fix-slab-use-after-free-Read-in-l2ca.patch. - Refresh patches.suse/Bluetooth-hci_event-Fix-not-using-key-encryption-siz.patch. - Refresh patches.suse/Bluetooth-hci_sync-Fix-UAF-in-hci_acl_create_conn_sy.patch. - commit 22a7d25 - Bluetooth: hci_conn: Fix sending BT_HCI_CMD_LE_CREATE_CONN_CANCEL (git-fixes). - commit defb49e - Bluetooth: mgmt: remove NULL check in add_ext_adv_params_complete() (CVE-2025-38117 bsc#1245695). - Bluetooth: mgmt: remove NULL check in mgmt_set_connectable_complete() (CVE-2025-38117 bsc#1245695). - commit 3217653 - bluetooth: restore le_scan_restart in struct hci_dev (CVE-2025-38117 bsc#1245695). - commit 7e7eb69 - Bluetooth: hci_core: Remove le_restart_scan work (CVE-2025-38117 bsc#1245695). - commit 9530108 - Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT (CVE-2025-38335 bsc#1246250). - commit 4b421f0 - Correctly put RDMA kabi patch into patches.kabi instead of patches.suse - commit 0433d1f - kABI workaround for bluetooth hci_dev changes (CVE-2025-38250 bsc#1246182). - commit 2bfeee5 - Bluetooth: hci_core: Fix use-after-free in vhci_flush() (CVE-2025-38250 bsc#1246182). - commit 45dea35 - selftests/bpf: Support more socket types in create_pair() (bsc#1239470 CVE-2025-21854). - selftests/bpf: Refactor out helper functions for a few tests (bsc#1239470 CVE-2025-21854). - commit 21d7fea - mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when dissolve_free_hugetlb_folio() (bsc#1225707 CVE-2024-36028). - commit ce47e5b - Delete patches.suse/selftest-bpf-Add-test-for-af_vsock-poll.patch. It requires the &quot;bpf_program__attach_sockmap&quot; API in libbpf, which isn't backported. - Refresh patches.suse/selftest-bpf-Add-vsock-test-for-sockmap-rejecting-un.patch - commit a7dddad - i2c: stm32: fix the device used for the DMA map (git-fixes). - usb: hub: Don't try to recover devices lost during warm reset (git-fixes). - usb: musb: fix gadget state on disconnect (git-fixes). - thunderbolt: Fix bit masking in tb_dp_port_set_hops() (git-fixes). - thunderbolt: Fix wake on connect at runtime (git-fixes). - pch_uart: Fix dma_sync_sg_for_device() nents value (git-fixes). - comedi: Fix initialization of data for instructions that write to subdevice (git-fixes). - comedi: Fix use of uninitialized data in insn_rw_emulate_bits() (git-fixes). - comedi: das6402: Fix bit shift out of bounds (git-fixes). - comedi: aio_iiro_16: Fix bit shift out of bounds (git-fixes). - comedi: pcl812: Fix bit shift out of bounds (git-fixes). - comedi: das16m1: Fix bit shift out of bounds (git-fixes). - comedi: Fix some signed shift left operations (git-fixes). - comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too large (git-fixes). - iio: adc: ad7949: use spi_is_bpw_supported() (git-fixes). - iio: accel: fxls8962af: Fix use after free in fxls8962af_fifo_flush (git-fixes). - iio: adc: stm32-adc: Fix race in installing chained IRQ handler (git-fixes). - regmap: fix potential memory leak of regmap_bus (git-fixes). - Input: xpad - set correct controller type for Acer NGR200 (git-fixes). - commit 08dfa63 - jfs: Fix null-ptr-deref in jfs_ioc_trim (bsc#1246044 CVE-2025-38203). - commit e88ea13 - hwmon: (corsair-cpro) Validate the size of the received input buffer (git-fixes). - drm/amdgpu/gfx8: reset compute ring wptr on the GPU on resume (git-fixes). - soundwire: amd: fix for clearing command status register (git-fixes). - dmaengine: nbpfaxi: Fix memory corruption in probe() (git-fixes). - phy: tegra: xusb: Fix unbalanced regulator disable in UTMI PHY mode (git-fixes). - memstick: core: Zero initialize id_reg in h_memstick_read_dev_id() (git-fixes). - mmc: bcm2835: Fix dma_unmap_sg() nents value (git-fixes). - mmc: sdhci_am654: Workaround for Errata i2312 (git-fixes). - mmc: sdhci-pci: Quirk for broken command queuing on Intel GLK-based Positivo models (git-fixes). - commit 0d9aae2 - net/sched: Return NULL when htb_lookup_leaf encounters an empty rbtree (git-fixes). - commit fb42307 - ipv6: mcast: Delay put pmc-&gt;idev in mld_del_delrec() (git-fixes). - commit 505c14c - rpl: Fix use-after-free in rpl_do_srh_inline() (git-fixes). - commit 3342938 - af_packet: fix the SO_SNDTIMEO constraint not effective on tpacked_snd() (git-fixes). - commit 877c186 - net/sched: sch_qfq: Fix race condition on qfq_aggregate (git-fixes). - commit 2e8a829 - kABI workaround for struct drm_framebuffer changes (git-fixes). - commit 7b3cefa - drm/framebuffer: Acquire internal references on GEM handles (git-fixes). - commit 736ff8d - Bluetooth: L2CAP: Fix attempting to adjust outgoing MTU (git-fixes). - Bluetooth: btusb: QCA: Fix downloading wrong NVM for WCN6855 GF variant without board ID (git-fixes). - Bluetooth: SMP: Fix using HCI_ERROR_REMOTE_USER_TERM on timeout (git-fixes). - Bluetooth: SMP: If an unallowed command is received consider it a failure (git-fixes). - Bluetooth: hci_sync: fix connectable extended advertising when using static random address (git-fixes). - Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb() (git-fixes). - usb: net: sierra: check for no status endpoint (git-fixes). - net: phy: Don't register LEDs for genphy (git-fixes). - drm/gem: Fix race in drm_gem_handle_create_tail() (stable-fixes). - wifi: prevent A-MSDU attacks in mesh networks (stable-fixes). - Revert &quot;ACPI: battery: negate current when discharging&quot; (stable-fixes). - usb: cdnsp: Fix issue with CV Bad Descriptor test (git-fixes). - drm/gem: Acquire references on GEM handles for framebuffers (stable-fixes). - vt: add missing notification when switching back to text mode (stable-fixes). - ASoC: amd: yc: add quirk for Acer Nitro ANV15-41 internal mic (stable-fixes). - ALSA: hda/realtek - Enable mute LED on HP Pavilion Laptop 15-eg100 (stable-fixes). - HID: lenovo: Add support for ThinkPad X1 Tablet Thin Keyboard Gen2 (stable-fixes). - HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY (stable-fixes). - HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras (stable-fixes). - net: usb: qmi_wwan: add SIMCom 8230C composition (stable-fixes). - usb: cdnsp: Replace snprintf() with the safer scnprintf() variant (stable-fixes). - usb:cdnsp: remove TRB_FLUSH_ENDPOINT command (stable-fixes). - commit b8ce602 - Refresh patches.suse/selftests-bpf-Add-tests-for-iter-next-method-returni.patch. Fix BPF selftests build failure in progs/iters_testmod.c due to missing definition of 'struct bpf_iter_task_vma' and 'bpf_iter_task_vma()'. - commit ca03a47 - ptp: fix breakage after ptp_vclock_in_use() rework (bsc#1246506). - commit 001cddf - x86/virt/tdx: Avoid indirect calls to TDX assembly functions (git-fixes). - commit 9c296c1 - soc: aspeed: lpc-snoop: Don't disable channels that aren't enabled (git-fixes). - soc: aspeed: lpc-snoop: Cleanup resources in stack-order (git-fixes). - HID: core: ensure __hid_request reserves the report ID as the first byte (git-fixes). - commit 5cd5cd3 - drm/msm/a7xx: Call CP_RESET_CONTEXT_STATE (CVE-2025-38188 bsc#1246098). - drm/msm/a6xx+: Insert a fence wait before SMMU table update (CVE-2025-38188 bsc#1246098). - commit e22ddaf - x86/iopl: Cure TIF_IO_BITMAP inconsistencies (CVE-2025-38100 bsc#1245650). - commit 143bbc6 - Bluetooth: eir: Fix possible crashes on eir_create_adv_data (CVE-2025-38303 bsc#1246354). - commit 89447f6 - btrfs: explicitly ref count block_group on new_bgs list (bsc#1243068) - commit 8647d2c - btrfs: make btrfs_discard_workfn() block_group ref explicit (bsc#1243068) - commit 32e19f5 - btrfs: harden block_group::bg_list against list_del() races (CVE-2025-37856 bsc#1243068) - commit 3333359 - btrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref (CVE-2025-38034 bsc#1244792) - commit 55c0ec4 - btrfs: do not BUG_ON() when freeing tree block after error (CVE-2024-44963 1230216) - commit d292416 - scsi: megaraid_sas: Fix invalid node index (CVE-2025-38239 bsc#1246178). - seg6: Fix validation of nexthop addresses (CVE-2025-38310 bsc#1246361). - x86/sgx: Prevent attempts to reclaim poisoned pages (CVE-2025-38334 bsc#1246384). - commit 740f6c2 - selftests/bpf: Add tests with stack ptr register in conditional jmp (bsc#1246264 CVE-2025-38279). - bpf: Do not include stack ptr register in precision backtracking bookkeeping (bsc#1246264 CVE-2025-38279). - Refresh patches.kabi/bpf-verifier-kABI-workarounds.patch - commit ccc2c5b - bridge: mcast: Fix use-after-free during router port configuration (CVE-2025-38248 bsc#1246173). - 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 01133bb - iommu/amd: Set the pgsize_bitmap correctly (git-fixes). - commit 8746ec5 - scsi: core: Enforce unlimited max_segment_size when virt_boundary_mask is set (git-fixes). - scsi: qla4xxx: Fix missing DMA mapping error in qla4xxx_alloc_pdu() (git-fixes). - scsi: qla2xxx: Fix DMA mapping test in qla24xx_get_port_database() (git-fixes). - scsi: megaraid_sas: Fix invalid node index (git-fixes). - aoe: clean device rq_list in aoedev_downdev() (git-fixes). - md/md-bitmap: fix dm-raid max_write_behind setting (git-fixes). - commit 2e07501 - dm-bufio: fix sched in atomic context (git-fixes). - commit c664ddf - Update patches.suse/nvme-pci-fix-queue-unquiesce-check-on-slot_reset.patch (git-fixes bsc#1240885). - commit 08c0025 - perf: Fix sample vs do_exit() (bsc#1246547). - commit 5327721 - nvme-pci: refresh visible attrs after being checked (git-fixes). - nvme: Fix incorrect cdw15 value in passthru error logging (git-fixes). - commit c5d3460 - scsi: lpfc: Copyright updates for 14.4.0.10 patches (bsc#1245260 bsc#1243100 bsc#1246125). - commit 58f7c6e - scsi: lpfc: Update lpfc version to 14.4.0.10 (bsc#1245260 bsc#1243100 bsc#1246125). - scsi: lpfc: Modify end-of-life adapters' model descriptions (bsc#1245260 bsc#1243100 bsc#1246125 bsc#1204142). - scsi: lpfc: Revise CQ_CREATE_SET mailbox bitfield definitions (bsc#1245260 bsc#1243100 bsc#1246125). - scsi: lpfc: Move clearing of HBA_SETUP flag to before lpfc_sli4_queue_unset (bsc#1245260 bsc#1243100 bsc#1246125). - scsi: lpfc: Ensure HBA_SETUP flag is used only for SLI4 in dev_loss_tmo_callbk (bsc#1245260 bsc#1243100 bsc#1246125). - scsi: lpfc: Relocate clearing initial phba flags from link up to link down hdlr (bsc#1245260 bsc#1243100 bsc#1246125). - scsi: lpfc: Simplify error handling for failed lpfc_get_sli4_parameters cmd (bsc#1245260 bsc#1243100 bsc#1246125). - scsi: lpfc: Early return out of FDMI cmpl for locally rejected statuses (bsc#1245260 bsc#1243100 bsc#1246125). - scsi: lpfc: Skip RSCN processing when FC_UNLOADING flag is set (bsc#1245260 bsc#1243100 bsc#1246125). - scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure (bsc#1245260 bsc#1243100 bsc#1246125). - scsi: lpfc: Update debugfs trace ring initialization messages (bsc#1245260 bsc#1243100 bsc#1246125). - scsi: lpfc: Revise logging format for failed CT MIB requests (bsc#1245260 bsc#1243100 bsc#1246125). - commit 14dcfed - Update patches.suse/net-clear-the-dst-when-changing-skb-protocol.patch (bsc#1245954 CVE-2025-38192). Fix incorrect CVE reference. - commit 288e8f6 - drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() (bsc#1245951 CVE-2025-38187) - commit 62c6956 - bpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem() (bsc#1245980 CVE-2025-38202). - commit 630834e - selftest/bpf/benchs: Add benchmark for sockmap usage (bsc#1245749 CVE-2025-38154). - commit ac96089 - bpf, sockmap: Avoid using sk_socket after free when sending (bsc#1245749 CVE-2025-38154). - bpf, sockmap: Fix panic when calling skb_linearize (bsc#1245749 CVE-2025-38154). - bpf, sockmap: fix duplicated data transmission (bsc#1245749 CVE-2025-38154). - bpf, sockmap: Fix data lost during EAGAIN retries (bsc#1245749 CVE-2025-38154). - commit bc1361f - bpf: Fix memory leak in bpf_core_apply (git-fixes). - commit 44b4ba3 - bpf/selftests: Check errno when percpu map value size exceeds (git-fixes). - bpf: Check percpu map value size first (git-fixes). - commit 81feacb - bpftool: Fix undefined behavior caused by shifting into the sign bit (git-fixes). - commit 9363920 - ipc: fix to protect IPCS lookups using RCU (CVE-2025-38212 bsc#1246029). - commit 9ff5b2e - 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 74ee184 - ucsi_operations: add stubs for all operations (git-fixes). - commit 1e9baf6 - drm/amd/display: Don't treat wb connector as physical in (bsc#1245654 CVE-2025-38098) - commit 277f764 - selftests/bpf: Add tests for iter next method returning valid pointer (git-fixes). - bpf: Make the pointer returned by iter next method valid (git-fixes). - commit fcdc4ee - hisi_acc_vfio_pci: bugfix live migration function without VF device driver (CVE-2025-38283 bsc#1246273). - configfs-tsm-report: Fix NULL dereference of tsm_ops (CVE-2025-38210 bsc#1246020). - commit eef28a4 - kasan: remove kasan_find_vm_area() to prevent possible deadlock (git-fixes). - maple_tree: fix mt_destroy_walk() on root leaf node (git-fixes). - commit aaacc92 - drm/tegra: nvdec: Fix dma_alloc_coherent error check (git-fixes). - nbd: fix uaf in nbd_genl_connect() error path (git-fixes). - can: m_can: m_can_handle_lost_msg(): downgrade msg lost in rx message to debug level (git-fixes). - net: phy: microchip: limit 100M workaround to link-down events on LAN88xx (git-fixes). - wifi: mt76: mt7925: Fix null-ptr-deref in mt7925_thermal_init() (git-fixes). - wifi: mt76: mt7925: fix invalid array index in ssid assignment during hw scan (git-fixes). - wifi: mt76: mt7925: fix the wrong config for tx interrupt (git-fixes). - wifi: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev() (git-fixes). - commit 067b949 - xfs: fix off-by-one error in fsmap's end_daddr usage (bsc#1235837). - commit 919d943 - hisi_acc_vfio_pci: fix XQE dma address error (CVE-2025-38158 bsc#1245750). - commit 373ef61 - 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 45301b8 - platform/x86: think-lmi: Create ksets consecutively (stable-fixes). - Refresh patches.suse/platform-x86-think-lmi-Fix-kobject-cleanup.patch. - commit 5072bed - net: phy: smsc: Fix link failure in forced mode with Auto-MDIX (git-fixes). - net: phy: smsc: Fix Auto-MDIX configuration when disabled by strap (git-fixes). - Bluetooth: hci_event: Fix not marking Broadcast Sink BIS as connected (git-fixes). - Bluetooth: hci_sync: Fix not disabling advertising instance (git-fixes). - usb: xhci: quirk for data loss in ISOC transfers (stable-fixes). - Logitech C-270 even more broken (stable-fixes). - Input: xpad - support Acer NGR 200 Controller (stable-fixes). - dma-buf: fix timeout handling in dma_resv_wait_timeout v2 (stable-fixes). - mmc: sdhci: Add a helper function for dump register in dynamic debug mode (stable-fixes). - ACPICA: Refuse to evaluate a method if arguments are missing (stable-fixes). - mtd: spinand: fix memory leak of ECC engine conf (stable-fixes). - ASoC: amd: yc: update quirk data for HP Victus (stable-fixes). - ASoC: amd: yc: Add quirk for MSI Bravo 17 D7VF internal mic (stable-fixes). - ALSA: sb: Force to disable DMAs once when DMA mode is changed (stable-fixes). - ALSA: sb: Don't allow changing the DMA mode during operations (stable-fixes). - drm/msm: Fix another leak in the submit error path (stable-fixes). - drm/msm: Fix a fence leak in submit error path (stable-fixes). - regulator: fan53555: add enable_time support and soft-start times (stable-fixes). - wifi: ath6kl: remove WARN on bad firmware input (stable-fixes). - wifi: mac80211: drop invalid source address OCB frames (stable-fixes). - ata: pata_cs5536: fix build on 32-bit UML (stable-fixes). - platform/x86/amd/pmc: Add PCSpecialist Lafite Pro V 14M to 8042 quirks list (stable-fixes). - Revert &quot;drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1&quot; (stable-fixes). - wifi: mac80211: Add link iteration macro for link data (stable-fixes). - wifi: mac80211: chan: chandef is non-NULL for reserved (stable-fixes). - commit 66a4a55 - net: clear the dst when changing skb protocol (bsc#1245954 CVE-2024-49861). - commit eed1284 - usb: typec: ucsi: Set orientation as none when connector is unplugged (git-fixes). - commit 9b64a84 - usb: typec: ucsi: glink: fix off-by-one in connector_status (git-fixes). - commit 63d64a6 - coresight: prevent deactivate active config while enabling the config (CVE-2025-38131 bsc#1245677). - coresight: holding cscfg_csdev_lock while removing cscfg from csdev (CVE-2025-38132 bsc#1245679). - commit f8db328 - ACPI: PRM: Reduce unnecessary printing to avoid user confusion (bsc#1246122). - commit f060328 - usb: typec: ucsi: Fix busy loop on ASUS VivoBooks (git-fixes). - usb: typec: ucsi: Fix the partner PD revision (git-fixes). - commit cb5cfe6 - restore UCSI_CONNECTOR_RESET_HARD definition (git-fixes). - commit 3a50af7 - usb: typec: ucsi: Add DATA_RESET option of Connector Reset command (git-fixes). - commit ebc917a - pinctrl: amd: Clear GPIO debounce for suspend (git-fixes). - pinctrl: qcom: msm: mark certain pins as invalid for interrupts (git-fixes). - commit 7a0a421 - efi/mokvar-table: Avoid repeated map/unmap of the same page (bsc#1240323 CVE-2025-21872). - commit a16e799 - usb: typec: ucsi: move ucsi_acknowledge() from ucsi_read_error() (git-fixes). - commit 9793505 - kabi: restore encap_sk in struct xfrm_state (CVE-2025-38097 bsc#1245660). - espintcp: remove encap socket caching to avoid reference leak (CVE-2025-38097 bsc#1245660). - commit 94f2735 - net: lan743x: fix potential out-of-bounds write in lan743x_ptp_io_event_clock_get() (CVE-2025-38183 bsc#1246006). - commit 0eb12cd - net_sched: sch_sfq: fix a potential crash on gso_skb handling (CVE-2025-38115 bsc#1245689). - commit 6a4ffd3 - usb: typec: ucsi_acpi: Add LG Gram quirk (git-fixes). - commit da7fb49 - usb: typec: ucsi: don't retrieve PDOs if not supported (git-fixes). - commit d303a5e - usb: typec: ucsi: Delay alternate mode discovery (git-fixes). - commit b7ba22d - usb: typec: Update sysfs when setting ops (git-fixes). - commit b336d78 - usb: typec: ucsi: glink: increase max ports for x1e80100 (git-fixes). - commit 31de9c9 - ucsi_ops: adapt update_connector to kABI consistency (git-fixes). - usb: typec: ucsi: add update_connector callback (git-fixes). - blacklist.conf: needed for infrastructure. kABI fix added - Refresh patches.kabi/struct-ucsi_operations-use-padding-for-new-operation.patch. - Refresh patches.suse/paddings-add-paddings-to-TypeC-stuff.patch. - commit a70b9ee - ALSA: usb-audio: Kill timer properly at removal (CVE-2025-38105 bsc#1245682). - commit 2bf6099 - x86/process: Move the buffer clearing before MONITOR (bsc#1238896 CVE-2024-36350 CVE-2024-36357 CVE-2024-36348 CVE-2024-36349). - commit 9303368 - usb: typec: ucsi: glink: use typec_set_orientation (git-fixes). - Refresh patches.suse/soc-qcom-pmic_glink-Fix-race-during-initialization.patch. - Refresh patches.suse/usb-typec-ucsi-glink-fix-child-node-release-in-probe.patch. - commit b105e3e - KVM: SVM: Advertise TSA CPUID bits to guests (bsc#1238896 CVE-2024-36350 CVE-2024-36357 CVE-2024-36348 CVE-2024-36349). - commit 67b316f - Bluetooth: btusb: Fix regression in the initialization of fake Bluetooth controllers (CVE-2025-38099 bsc#1245671). - Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/broken (CVE-2025-38099 bsc#1245671). - Bluetooth: Add quirk for broken READ_PAGE_SCAN_TYPE (CVE-2025-38099 bsc#1245671). - Bluetooth: Add quirk for broken READ_VOICE_SETTING (CVE-2025-38099 bsc#1245671). - commit 254e65a - jfs: fix array-index-out-of-bounds read in add_missing_indices (bsc#1245983 CVE-2025-38204). - commit 65d9d7f - usb: typec: ucsi_glink: drop NO_PARTNER_PDOS quirk for sm8550 / sm8650 (git-fixes). - commit 380eca4 - usb: typec: ucsi_glink: enable the UCSI_DELAY_DEVICE_PDOS quirk on qcm6490 (git-fixes). - commit 3de42d7 - usb: typec: ucsi_glink: enable the UCSI_DELAY_DEVICE_PDOS quirk (git-fixes). - commit 2a3ce34 - usb: typec: ucsi_glink: rework quirks implementation (git-fixes). - commit b78f907 - usb: typec: ucsi: support delaying GET_PDOS for device (git-fixes). - Refresh patches.kabi/struct-usci-hide-additional-member.patch. - commit 95f3b03 - rpm/mkspec: Fix missing kernel-syms-rt creation (bsc#1244337) - commit 630f139 - usb: typec: ucsi: extract code to read PD caps (git-fixes). - commit ebc6c46 - usb: typec: ucsi: properly register partner's PD device (git-fixes). - commit 7b95fc1 - usb: typec: ucsi: fix UCSI on SM8550 &amp; SM8650 Qualcomm devices (git-fixes). - commit c40444f - usb: typec: ucsi: Add qcm6490-pmic-glink as needing PDOS quirk (git-fixes). - commit 46f5c2a - ucsi_ccg: Refine the UCSI Interrupt handling (git-fixes). - commit e97f436 - exfat: fix double free in delayed_free (bsc#1246073 CVE-2025-38206). - commit 38c1950 - usb: typec: ucsi: Get PD revision for partner (git-fixes). - commit a80ec70 - x86/bugs: Add a Transient Scheduler Attacks mitigation (bsc#1238896 CVE-2024-36350 CVE-2024-36357 CVE-2024-36348 CVE-2024-36349). - Update config files. - commit 45d6a14 - pwm: mediatek: Ensure to disable clocks in error path (git-fixes). - ASoC: cs35l56: probe() should fail if the device ID is not recognized (git-fixes). - ASoC: fsl_asrc: use internal measured ratio for non-ideal ratio mode (git-fixes). - commit 5b2c070 - dm-raid: fix variable in journal device check (git-fixes). - commit 7e51a3f - dm-verity: fix a memory leak if some arguments are specified multiple times (git-fixes). - commit 18c3347 - dm-mirror: fix a tiny race condition (git-fixes). - commit 6d6aef6 - dm-flakey: make corrupting read bios work (git-fixes). - commit bbf383a - dm-flakey: error all IOs when num_features is absent (git-fixes). - commit d4d758e - dm: free table mempools if not used in __bind (git-fixes). - commit 6abd700 - dm: don't change md if dm_table_set_restrictions() fails (git-fixes). - commit 0d534aa - dm: restrict dm device size to 2^63-512 bytes (git-fixes). - commit 240dadc - virtgpu: don't reset on shutdown (git-fixes). - commit 82f42df - kernel/fork: only call untrack_pfn_clear() on VMAs duplicated for fork() (git-fix for CVE-2025-22090 bsc#1241537). - commit 852f7f4 - netfilter: nft_set_pipapo: prevent overflow in lookup table allocation (CVE-2025-38162 bsc#1245752). - commit c7520cc - efi: Don't map the entire mokvar table to determine its size (bsc#1240323 CVE-2025-21872). - commit aefffb0 - ucsi-glink: adapt to kABI consistency (git-fixes). - usb: typec: ucsi: glink: move GPIO reading into connector_status callback (git-fixes). - Refresh patches.suse/usb-typec-ucsi-Move-unregister-out-of-atomic-section.patch. - commit 8ae6c79 - vhost-scsi: protect vq-&gt;log_used with vq-&gt;mutex (CVE-2025-38074 bsc#1244735). - commit 29ecfb7 - struct ucsi_operations: use padding for new operation (git-fixes). - commit 5fe6bda - crypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP() (CVE-2025-37984 bsc#1243669). - commit 4115893 - virtio: break and reset virtio devices on device_shutdown() (CVE-2025-38064 bsc#1245201). - commit 1ef712f - usb: typec: ucsi: add callback for connector status updates (git-fixes). - blacklist.conf: needed as infrastructure. kABI workaround following - Refresh patches.suse/paddings-add-paddings-to-TypeC-stuff.patch. - Refresh patches.suse/usb-typec-ucsi-displayport-Fix-deadlock.patch. - commit de5a5b0 - struct cdns: move new member to the end (git-fixes). - commit 4384b08 - usb: cdnsp: Fix issue with resuming from L1 (git-fixes). - commit c8b7c96 - net: dsa: clean up FDB, MDB, VLAN entries on unbind (CVE-2025-37864 bsc#1242965). - commit d1f463e - NFSv4: Always set NLINK even if the server doesn't support it (git-fixes). - commit 84005c5 - NFSv4.2: fix listxattr to return selinux security label (git-fixes). - commit 0319baa - NFSv4: xattr handlers should check for absent nfs filehandles (git-fixes). - commit 80ac5a3 - sunrpc: don't immediately retransmit on seqno miss (git-fixes). - commit ceebf6f - fs/jfs: consolidate sanity checking in dbMount (git-fixes). - commit 5c4bc1b - objtool: Ignore end-of-section jumps for KCOV/GCOV (git-fixes). - commit e383ffb - objtool: Silence more KCOV warnings, part 2 (git-fixes). - commit ddae9d6 - netfilter: nf_set_pipapo_avx2: fix initial map fill (git-fixes CVE-2024-57947 bsc#1236333). - commit cedcb24 - usb: typec: displayport: Fix potential deadlock (git-fixes). - commit a45e2f9 - drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type (git-fixes). - ASoC: amd: yc: Add DMI quirk for Lenovo IdeaPad Slim 5 15 (stable-fixes). - Bluetooth: L2CAP: Fix L2CAP MTU negotiation (stable-fixes). - drm/amdkfd: Fix race in GWS queue scheduling (stable-fixes). - ASoC: codecs: wcd9335: Fix missing free of regulator supplies (git-fixes). - ALSA: hda: Ignore unsol events for cards being shut down (stable-fixes). - ALSA: hda: Add new pci id for AMD GPU display HD audio controller (stable-fixes). - usb: dwc2: also exit clock_gating when stopping udc while suspended (stable-fixes). - usb: potential integer overflow in usbg_make_tpg() (stable-fixes). - usb: common: usb-conn-gpio: use a unique name for usb connector device (stable-fixes). - usb: Add checks for snprintf() calls in usb_alloc_dev() (stable-fixes). - usb: cdc-wdm: avoid setting WDM_READ for ZLP-s (stable-fixes). - usb: typec: displayport: Receive DP Status Update NAK request exit dp altmode (stable-fixes). - usb: typec: mux: do not return on EOPNOTSUPP in {mux, switch}_set (stable-fixes). - iio: pressure: zpa2326: Use aligned_s64 for the timestamp (stable-fixes). - iio: adc: ad_sigma_delta: Fix use of uninitialized status_pos (stable-fixes). - drm/scheduler: signal scheduled fence when kill job (stable-fixes). - amd/amdkfd: fix a kfd_process ref leak (stable-fixes). - drm/amdgpu: amdgpu_vram_mgr_new(): Clamp lpfn to total vram (stable-fixes). - dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before using (stable-fixes). - dmaengine: xilinx_dma: Set dma_device directions (stable-fixes). - PCI: dwc: Make link training more robust by setting PORT_LOGIC_LINK_WIDTH to one lane (stable-fixes). - leds: multicolor: Fix intensity setting while SW blinking (stable-fixes). - mfd: max14577: Fix wakeup source leaks on device unbind (stable-fixes). - hwmon: (pmbus/max34440) Fix support for max34451 (stable-fixes). - drm/bridge: ti-sn65dsi86: make use of debugfs_init callback (stable-fixes). - ASoC: codec: wcd9335: Convert to GPIO descriptors (stable-fixes). - types: Complement the aligned types with signed 64-bit one (stable-fixes). - ASoC: codecs: wcd9335: Handle nicer probe deferral and simplify with dev_err_probe() (stable-fixes). - commit 9aa1e05 - i2c/designware: Fix an initialization issue (git-fixes). - commit d80f186 - powercap: intel_rapl: Do not change CLAMPING bit if ENABLE bit cannot be changed (git-fixes). - regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods (git-fixes). - spi: spi-fsl-dspi: Clear completion counter before initiating transfer (git-fixes). - platform/x86: think-lmi: Fix sysfs group cleanup (git-fixes). - platform/x86: think-lmi: Fix kobject cleanup (git-fixes). - platform/mellanox: mlxreg-lc: Fix logic error in power state check (git-fixes). - platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks (git-fixes). - platform/mellanox: nvsw-sn2201: Fix bus number in adapter error message (git-fixes). - platform/mellanox: mlxbf-pmc: Fix duplicate event ID for CACHE_DATA1 (git-fixes). - platform/mellanox: mlxbf-tmfifo: fix vring_desc.len assignment (git-fixes). - xhci: dbc: Flush queued requests before stopping dbc (git-fixes). - xhci: dbctty: disable ECHO flag by default (git-fixes). - xhci: Disable stream for xHC controller with XHCI_BROKEN_STREAMS (git-fixes). - usb: typec: altmodes/displayport: do not index invalid pin_assignments (git-fixes). - Revert &quot;usb: xhci: Implement xhci_handshake_check_state() helper&quot; (git-fixes). - usb: xhci: Skip xhci_reset in xhci_resume if xhci is being removed (git-fixes). - usb: gadget: u_serial: Fix race condition in TTY wakeup (git-fixes). - usb: chipidea: udc: disconnect/reconnect from host when do suspend/resume (git-fixes). - usb: cdnsp: do not disable slot for disabled slot (git-fixes). - Input: iqs7222 - explicitly define number of external channels (git-fixes). - Input: xpad - adjust error handling for disconnect (git-fixes). - drm/exynos: fimd: Guard display clock control with runtime PM calls (git-fixes). - drm/exynos: exynos7_drm_decon: add vblank check in IRQ handling (git-fixes). - drm/i915/gsc: mei interrupt top half should be in irq disabled context (git-fixes). - drm/i915/gt: Fix timeline left held on VMA alloc error (git-fixes). - drm/i915/selftests: Change mock_request() to return error pointers (git-fixes). - drm/sched: Increment job count before swapping tail spsc queue (git-fixes). - drm/bridge: panel: move prepare_prev_first handling to drm_panel_bridge_add_typed (git-fixes). - drm/ttm: fix error handling in ttm_buffer_object_transfer (git-fixes). - powercap: call put_device() on an error path in powercap_register_control_type() (stable-fixes). - commit d0cb71b - dm: fix unconditional IO throttle caused by REQ_PREFLUSH (CVE-2025-38063 bsc#1245202). - commit 65fa7b7 - smb: client: Fix use-after-free in cifs_fill_dirent (CVE-2025-38051 bsc#1244750). - commit 0f203bf - cgroup,freezer: fix incomplete freezing when attaching tasks (bsc#1245789). - commit 1970df7 - cgroup/cpuset: Extend kthread_is_per_cpu() check to all PF_NO_SETAFFINITY tasks (bsc#1241166). - commit 86012b8 - objtool: Stop UNRET validation on UD2 (git-fixes). - commit 0be0bc6 - objtool: Fix INSN_CONTEXT_SWITCH handling in validate_unret() (git-fixes). - commit f1073e2 - objtool: Properly disable uaccess validation (git-fixes). - commit b170301 - mm/memory-failure: fix handling of dissolved but not taken off from buddy pages (CVE-2024-39298 bsc#1227082). Refreshed: blacklist.conf: De-blacklist 8cf360b9d6a840700e06864236a01a883b34bbad - commit 1d1f80f - rose: fix dangling neighbour pointers in rose_rt_device_down() (git-fixes). - Bluetooth: MGMT: mesh_send: check instances prior disabling advertising (git-fixes). - Bluetooth: MGMT: set_mesh: update LE scan interval and window (git-fixes). - Bluetooth: hci_sync: revert some mesh modifications (git-fixes). - Bluetooth: Prevent unintended pause by checking if advertising is active (git-fixes). - net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect (git-fixes). - commit 9d01c7e - objtool: Silence more KCOV warnings (git-fixes). - commit 246e013 - objtool: Fix error handling inconsistencies in check() (git-fixes). - commit 2b123dd - objtool: Ignore dangling jump table entries (git-fixes). - commit 694bcb3 - objtool: Fix UNWIND_HINT_{SAVE,RESTORE} across basic blocks (git-fixes). - commit 24df4fe - x86/tdx: Fix __noreturn build warning around __tdx_hypercall_failed() (git-fixes). - Refresh patches.suse/x86-virt-tdx-Define-TDX-supported-page-sizes-as-macros.patch. - commit 741a25e - objtool: Fix _THIS_IP_ detection for cold functions (git-fixes). - commit b2539b9 - nvmet-tcp: don't restore null sk_state_change (bsc#1244801 CVE-2025-38035). - commit a1cc55e - s390/pci: Fix stale function handles in error handling (git-fixes bsc#1245647). - commit 1f0ecfd - s390/pci: Do not try re-enabling load/store if device is disabled (git-fixes bsc#1245646). - commit a7a5884 - NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN (git-fixes). - commit cbe692c - nfs: Clean up /proc/net/rpc/nfs when nfs_fs_proc_net_init() fails (git-fixes). - commit 29c2a95 - IB/mlx5: Fix potential deadlock in MR deregistration (git-fixes) - commit a31c762 - RDMA/mlx5: Fix vport loopback for MPV device (git-fixes) - commit 50aa3ad - RDMA/mlx5: Fix CC counters query for MPV (git-fixes) - commit 6fac6aa - RDMA/mlx5: Fix HW counters query for non-representor devices (git-fixes) - commit f645a5e - RDMA/mlx5: Initialize obj_event-&gt;obj_sub_list before xa_insert (git-fixes) - commit 9bf32eb - mtk-sd: reset host-&gt;mrq on prepare_data() error (git-fixes). - commit 85b8654 - Revert &quot;mmc: sdhci: Disable SD card clock before changing parameters&quot; (git-fixes). - mtk-sd: Prevent memory corruption from DMA map failure (git-fixes). - mtk-sd: Fix a pagefault in dma_unmap_sg() for not prepared data (git-fixes). - mmc: core: sd: Apply BROKEN_SD_DISCARD quirk earlier (git-fixes). - commit 4977a9e - kABI workaround for xsk: Fix race condition in AF_XDP generic RX path (CVE-2025-37920 bsc#1243479). - commit 2cbaa5f - xsk: Fix race condition in AF_XDP generic RX path (CVE-2025-37920 bsc#1243479). - commit b0fed9b - bpf, sockmap: Fix sk_msg_reset_curr (git-fixes). - commit 3936762 - scsi: s390: zfcp: Ensure synchronous unit_add (git-fixes bsc#1245599). - commit 4cb28a8 - s390/pkey: Prevent overflow in size calculation for memdup_user() (git-fixes bsc#1245598). - commit 458c9d8 - s390: Add z17 elf platform (LTC#214086 bsc#1245540). - commit a338278 - net: pktgen: fix access outside of user given buffer in pktgen_thread_write() (CVE-2025-38061 bsc#1245440). - commit 386f111 - net: tipc: fix refcount warning in tipc_aead_encrypt (CVE-2025-38052 bsc#1244749). - net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done (CVE-2025-38052 bsc#1244749). - commit 39309cf Package libnvme was updated: - Update to version 1.8+84.g73e0811d: * tree: do not try to strdup NULL pointer (bsc#1247225) * tree: always set the host key (bsc#1246560) Package open-iscsi was updated: - Update to version 2.1.11.suse+73.1723affc: * README for rpm build directory * Fix issue with IPv6 adapter interfaces (#508) (bsc#1240969) * fwparam_ppc.c: Fix the calloc-transposed-args issue (#504) * Makefile: fix &quot;No rule to make target 'iscsiuio/Makefile.in&quot; issue (#506) * Fix typo in initiator.c (#507) * Fix iscsid.conf NOP configuration (bsc#1240541) * doc: fixup iscsiadm man page option for -r (#501) * Modify log function to print session id (#498) * Fix minor typo (&quot;authenticaton&quot;) (#500) * Preparing for version 2.1.11 (#499) * iscsid: Rate limit session reopen log messages (#492) * IPv6 support for iBFT iSCSI boot (#493) * Improve iscsiadm command line parsing messages (#494) * More testing cleanup, and fix dprint test usage (#491) * Fix a typo in test/README (#486) * iscsid: Fix hang during login with scan=manual (#485) * fix 4 issues which are finded when building with clang 17 (#478) Package openssl-3 was updated: - Increase limit for CRL download [bsc#1247148, bsc#1247144] * Add openssl-3-large-CRLs.patch Package libzypp was updated: - Fix evaluation of libproxy results (bsc#1247690)- Replace URL variables inside mirrorlist/metalink files (fixes #667) - version 17.37.16 (35) - Append RepoInfo::path() to the mirror URLs in Preloader (bsc#1247054) - version 17.37.15 (35) - During installation indicate the backend being used (bsc#1246038) If some package actually needs to know, it should test for ZYPP_CLASSIC_RPMTRANS being set in the environment. Otherwise the transaction is driven by librpm. - version 17.37.14 (35) - Workaround 'rpm -vv' leaving scriptlets /var/tmp (bsc#1218459) - Verbose log libproxy results if PX_DEBUG=1 is set. - BuildRequires: cmake &gt;= 3.17. - version 17.37.13 (35) - Allow explicit request to probe an added repo's URL (bsc#1246466) - Fix tests with -DISABLE_MEDIABACKEND_TESTS=1 (fixes #661) - version 17.37.12 (35) - Add runtime check for a broken rpm-4.18.0 --runpostrans (bsc#1246149) - Add regression test for bsc#1245220 and some other filesize related tests. - version 17.37.11 (35) Package nvme-cli was updated: - Update to version 2.8+94.gbf4a448c: * netapp-ontapdev: update invalid device handling (bsc#1247017) * netapp-smdev: update invalid device handling (bsc#1247017) 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] Package systemd-presets-branding-SLE was updated: - enable sysstat_collect.timer and sysstat_summary.timer [bsc#1244553] and [bsc#1246835] - modified sources % default-SLE.preset Package zypper was updated: - Fix addrepo to handle explicit --check and --no-check requests (bsc#1246466) - Accept &quot;show&quot; as alias for &quot;info&quot; (bsc#1245985) - version 1.14.93 The CVRF data is provided by SUSE under the Creative Commons License 4.0 with Attribution (CC-BY-4.0). https://publiccloudimagechangeinfo.suse.com/google/sles-15-sp6-chost-byos-v20250918-x86-64/ Public Cloud Image Info https://www.suse.com/support/security/rating/ SUSE Security Ratings Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 cpupower-6.4.0-150600.4.6.6 curl-8.14.1-150600.4.28.1 glibc-2.38-150600.14.37.1 glibc-locale-2.38-150600.14.37.1 glibc-locale-base-2.38-150600.14.37.1 kernel-default-6.4.0-150600.23.65.1 libbrotlicommon1-1.0.7-150200.3.5.1 libbrotlidec1-1.0.7-150200.3.5.1 libcpupower1-6.4.0-150600.4.6.6 libcurl4-8.14.1-150600.4.28.1 liblmdb-0_9_30-0.9.30-150500.3.2.1 libnvme-mi1-1.8+84.g73e0811d-150600.3.18.1 libnvme1-1.8+84.g73e0811d-150600.3.18.1 libopeniscsiusr0-0.2.0-150600.51.6.1 libopenssl3-3.1.4-150600.5.36.4 libzypp-17.37.16-150600.3.79.1 nvme-cli-2.8+94.gbf4a448c-150600.3.21.1 open-iscsi-2.1.11-150600.51.6.1 openssl-3-3.1.4-150600.5.36.4 pam-1.3.0-150000.6.86.1 rsyslog-8.2406.0-150600.12.8.1 rsyslog-module-relp-8.2406.0-150600.12.8.1 systemd-presets-branding-SLE-15.1-150600.35.3.1 zypper-1.14.93-150600.10.49.2 cpupower-6.4.0-150600.4.6.6 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 curl-8.14.1-150600.4.28.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 glibc-2.38-150600.14.37.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 glibc-locale-2.38-150600.14.37.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 glibc-locale-base-2.38-150600.14.37.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 kernel-default-6.4.0-150600.23.65.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 libbrotlicommon1-1.0.7-150200.3.5.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 libbrotlidec1-1.0.7-150200.3.5.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 libcpupower1-6.4.0-150600.4.6.6 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 libcurl4-8.14.1-150600.4.28.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 liblmdb-0_9_30-0.9.30-150500.3.2.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 libnvme-mi1-1.8+84.g73e0811d-150600.3.18.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 libnvme1-1.8+84.g73e0811d-150600.3.18.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 libopeniscsiusr0-0.2.0-150600.51.6.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 libopenssl3-3.1.4-150600.5.36.4 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 libzypp-17.37.16-150600.3.79.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 nvme-cli-2.8+94.gbf4a448c-150600.3.21.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 open-iscsi-2.1.11-150600.51.6.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 openssl-3-3.1.4-150600.5.36.4 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 pam-1.3.0-150000.6.86.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 rsyslog-8.2406.0-150600.12.8.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 rsyslog-module-relp-8.2406.0-150600.12.8.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 systemd-presets-branding-SLE-15.1-150600.35.3.1 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 zypper-1.14.93-150600.10.49.2 as a component of Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64 TSX Asynchronous Abort condition on some CPUs utilizing speculative execution may allow an authenticated user to potentially enable information disclosure via a side channel with local access. CVE-2019-11135 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate 2.1 AV:L/AC:L/Au:N/C:P/I:N/A:N 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-15-sp6-chost-byos-v20250918-x86-64:pam-1.3.0-150000.6.86.1 moderate When asked to both use a `.netrc` file for credentials and to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has an entry that matches the redirect target hostname but the entry either omits just the password or omits both login and password. CVE-2024-11053 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:curl-8.14.1-150600.4.28.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:libcurl4-8.14.1-150600.4.28.1 moderate When a protocol selection parameter option disables all protocols without adding any then the default set of protocols would remain in the allowed set due to an error in the logic for removing protocols. The below command would perform a request to curl.se with a plaintext protocol which has been explicitly disabled. curl --proto -all,-http http://curl.se The flaw is only present if the set of selected protocols disables the entire set of available protocols, in itself a command with no practical use and therefore unlikely to be encountered in real situations. The curl security team has thus assessed this to be low severity bug. CVE-2024-2004 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:curl-8.14.1-150600.4.28.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:libcurl4-8.14.1-150600.4.28.1 moderate libcurl skips the certificate verification for a QUIC connection under certain conditions, when built to use wolfSSL. If told to use an unknown/bad cipher or curve, the error path accidentally skips the verification and returns OK, thus ignoring any certificate problems. CVE-2024-2379 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:curl-8.14.1-150600.4.28.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:libcurl4-8.14.1-150600.4.28.1 moderate When an application tells libcurl it wants to allow HTTP/2 server push, and the amount of received headers for the push surpasses the maximum allowed limit (1000), libcurl aborts the server push. When aborting, libcurl inadvertently does not free all the previously allocated headers and instead leaks the memory. Further, this error condition fails silently and is therefore not easily detected by an application. CVE-2024-2398 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:curl-8.14.1-150600.4.28.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:libcurl4-8.14.1-150600.4.28.1 moderate libcurl did not check the server certificate of TLS connections done to a host specified as an IP address, when built to use mbedTLS. libcurl would wrongly avoid using the set hostname function when the specified hostname was given as an IP address, therefore completely skipping the certificate check. This affects all uses of TLS protocols (HTTPS, FTPS, IMAPS, POPS3, SMTPS, etc). CVE-2024-2466 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:curl-8.14.1-150600.4.28.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:libcurl4-8.14.1-150600.4.28.1 moderate In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when dissolve_free_hugetlb_folio() When I did memory failure tests recently, below warning occurs: DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 8 PID: 1011 at kernel/locking/lockdep.c:232 __lock_acquire+0xccb/0x1ca0 Modules linked in: mce_inject hwpoison_inject CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__lock_acquire+0xccb/0x1ca0 RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082 RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0 RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10 R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004 FS: 00007ff9f32aa740(0000) GS:ffffa1ce5fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff9f3134ba0 CR3: 00000008484e4000 CR4: 00000000000006f0 Call Trace: <TASK> lock_acquire+0xbe/0x2d0 _raw_spin_lock_irqsave+0x3a/0x60 hugepage_subpool_put_pages.part.0+0xe/0xc0 free_huge_folio+0x253/0x3f0 dissolve_free_huge_page+0x147/0x210 __page_handle_poison+0x9/0x70 memory_failure+0x4e6/0x8c0 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xbc/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff9f3114887 RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887 RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001 RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00 </TASK> Kernel panic - not syncing: kernel: panic_on_warn set ... CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> panic+0x326/0x350 check_panic_on_warn+0x4f/0x50 __warn+0x98/0x190 report_bug+0x18e/0x1a0 handle_bug+0x3d/0x70 exc_invalid_op+0x18/0x70 asm_exc_invalid_op+0x1a/0x20 RIP: 0010:__lock_acquire+0xccb/0x1ca0 RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082 RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0 RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10 R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004 lock_acquire+0xbe/0x2d0 _raw_spin_lock_irqsave+0x3a/0x60 hugepage_subpool_put_pages.part.0+0xe/0xc0 free_huge_folio+0x253/0x3f0 dissolve_free_huge_page+0x147/0x210 __page_handle_poison+0x9/0x70 memory_failure+0x4e6/0x8c0 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xbc/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff9f3114887 RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887 RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001 RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00 </TASK> After git bisecting and digging into the code, I believe the root cause is that _deferred_list field of folio is unioned with _hugetlb_subpool field. In __update_and_free_hugetlb_folio(), folio->_deferred_ ---truncated--- CVE-2024-36028 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate A transient execution vulnerability in some AMD processors may allow an attacker to infer data from previous stores, potentially resulting in the leakage of privileged information. CVE-2024-36350 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure: fix handling of dissolved but not taken off from buddy pages When I did memory failure tests recently, below panic occurs: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8cee00 flags: 0x6fffe0000000000(node=1|zone=2|lastcpupid=0x7fff) raw: 06fffe0000000000 dead000000000100 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000009 00000000ffffffff 0000000000000000 page dumped because: VM_BUG_ON_PAGE(!PageBuddy(page)) ------------[ cut here ]------------ kernel BUG at include/linux/page-flags.h:1009! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:__del_page_from_free_list+0x151/0x180 RSP: 0018:ffffa49c90437998 EFLAGS: 00000046 RAX: 0000000000000035 RBX: 0000000000000009 RCX: ffff8dd8dfd1c9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff8dd8dfd1c9c0 RBP: ffffd901233b8000 R08: ffffffffab5511f8 R09: 0000000000008c69 R10: 0000000000003c15 R11: ffffffffab5511f8 R12: ffff8dd8fffc0c80 R13: 0000000000000001 R14: ffff8dd8fffc0c80 R15: 0000000000000009 FS: 00007ff916304740(0000) GS:ffff8dd8dfd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055eae50124c8 CR3: 00000008479e0000 CR4: 00000000000006f0 Call Trace: <TASK> __rmqueue_pcplist+0x23b/0x520 get_page_from_freelist+0x26b/0xe40 __alloc_pages_noprof+0x113/0x1120 __folio_alloc_noprof+0x11/0xb0 alloc_buddy_hugetlb_folio.isra.0+0x5a/0x130 __alloc_fresh_hugetlb_folio+0xe7/0x140 alloc_pool_huge_folio+0x68/0x100 set_max_huge_pages+0x13d/0x340 hugetlb_sysctl_handler_common+0xe8/0x110 proc_sys_call_handler+0x194/0x280 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xc2/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff916114887 RSP: 002b:00007ffec8a2fd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000055eae500e350 RCX: 00007ff916114887 RDX: 0000000000000004 RSI: 000055eae500e390 RDI: 0000000000000003 RBP: 000055eae50104c0 R08: 0000000000000000 R09: 000055eae50104c0 R10: 0000000000000077 R11: 0000000000000246 R12: 0000000000000004 R13: 0000000000000004 R14: 00007ff916216b80 R15: 00007ff916216a00 </TASK> Modules linked in: mce_inject hwpoison_inject ---[ end trace 0000000000000000 ]--- And before the panic, there had an warning about bad page state: BUG: Bad page state in process page-types pfn:8cee00 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8cee00 flags: 0x6fffe0000000000(node=1|zone=2|lastcpupid=0x7fff) page_type: 0xffffff7f(buddy) raw: 06fffe0000000000 ffffd901241c0008 ffffd901240f8008 0000000000000000 raw: 0000000000000000 0000000000000009 00000000ffffff7f 0000000000000000 page dumped because: nonzero mapcount Modules linked in: mce_inject hwpoison_inject CPU: 8 PID: 154211 Comm: page-types Not tainted 6.9.0-rc4-00499-g5544ec3178e2-dirty #22 Call Trace: <TASK> dump_stack_lvl+0x83/0xa0 bad_page+0x63/0xf0 free_unref_page+0x36e/0x5c0 unpoison_memory+0x50b/0x630 simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110 debugfs_attr_write+0x42/0x60 full_proxy_write+0x5b/0x80 vfs_write+0xcd/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xc2/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f189a514887 RSP: 002b:00007ffdcd899718 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f189a514887 RDX: 0000000000000009 RSI: 00007ffdcd899730 RDI: 0000000000000003 RBP: 00007ffdcd8997a0 R08: 0000000000000000 R09: 00007ffdcd8994b2 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdcda199a8 R13: 0000000000404af1 R14: 000000000040ad78 R15: 00007f189a7a5040 </TASK> The root cause should be the below race: memory_failure try_memory_failure_hugetlb me_huge_page __page_handle_poison dissolve_free_hugetlb_folio drain_all_pages -- Buddy page can be isolated e.g. for compaction. take_page_off_buddy -- Failed as page is not in the ---truncated--- CVE-2024-39298 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages() Fix an unwind issue in mlx5vf_add_migration_pages(). If a set of pages is allocated but fails to be added to the SG table, they need to be freed to prevent a memory leak. Any pages successfully added to the SG table will be freed as part of mlx5vf_free_data_buffer(). CVE-2024-56742 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_set_pipapo: fix initial map fill The initial buffer has to be inited to all-ones, but it must restrict it to the size of the first field, not the total field size. After each round in the map search step, the result and the fill map are swapped, so if we have a set where f->bsize of the first element is smaller than m->bsize_max, those one-bits are leaked into future rounds result map. This makes pipapo find an incorrect matching results for sets where first field size is not the largest. Followup patch adds a test case to nft_concat_range.sh selftest script. Thanks to Stefano Brivio for pointing out that we need to zero out the remainder explicitly, only correcting memset() argument isn't enough. CVE-2024-57947 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important libcurl's ASN1 parser has this utf8asn1str() function used for parsing an ASN.1 UTF-8 string. Itcan detect an invalid field and return error. Unfortunately, when doing so it also invokes `free()` on a 4 byte localstack buffer. Most modern malloc implementations detect this error and immediately abort. Some however accept the input pointer and add that memory to its list of available chunks. This leads to the overwriting of nearby stack memory. The content of the overwrite is decided by the `free()` implementation; likely to be memory pointers and a set of flags. The most likely outcome of exploting this flaw is a crash, although it cannot be ruled out that more serious results can be had in special circumstances. CVE-2024-6197 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:curl-8.14.1-150600.4.28.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:libcurl4-8.14.1-150600.4.28.1 important libcurl's ASN1 parser code has the `GTime2str()` function, used for parsing an ASN.1 Generalized Time field. If given an syntactically incorrect field, the parser might end up using -1 for the length of the *time fraction*, leading to a `strlen()` getting performed on a pointer to a heap buffer area that is not (purposely) null terminated. This flaw most likely leads to a crash, but can also lead to heap contents getting returned to the application when [CURLINFO_CERTINFO](https://curl.se/libcurl/c/CURLINFO_CERTINFO.html) is used. CVE-2024-7264 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:curl-8.14.1-150600.4.28.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:libcurl4-8.14.1-150600.4.28.1 moderate When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine. If the returned status reports another error than 'revoked' (like for example 'unauthorized') it is not treated as a bad certficate. CVE-2024-8096 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:curl-8.14.1-150600.4.28.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:libcurl4-8.14.1-150600.4.28.1 moderate When curl is asked to use HSTS, the expiry time for a subdomain might overwrite a parent domain's cache entry, making it end sooner or later than otherwise intended. This affects curl using applications that enable HSTS and use URLs with the insecure `HTTP://` scheme and perform transfers with hosts like `x.example.com` as well as `example.com` where the first host is a subdomain of the second host. (The HSTS cache either needs to have been populated manually or there needs to have been previous HTTPS accesses done as the cache needs to have entries for the domains involved to trigger this problem.) When `x.example.com` responds with `Strict-Transport-Security:` headers, this bug can make the subdomain's expiry timeout *bleed over* and get set for the parent domain `example.com` in curl's HSTS cache. The result of a triggered bug is that HTTP accesses to `example.com` get converted to HTTPS for a different period of time than what was asked for by the origin server. If `example.com` for example stops supporting HTTPS at its expiry time, curl might then fail to access `http://example.com` until the (wrongly set) timeout expires. This bug can also expire the parent's entry *earlier*, thus making curl inadvertently switch back to insecure HTTP earlier than otherwise intended. CVE-2024-9681 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:curl-8.14.1-150600.4.28.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:libcurl4-8.14.1-150600.4.28.1 moderate When asked to use a `.netrc` file for credentials **and** to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. This flaw only manifests itself if the netrc file has a `default` entry that omits both login and password. A rare circumstance. CVE-2025-0167 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:curl-8.14.1-150600.4.28.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:libcurl4-8.14.1-150600.4.28.1 moderate libcurl would wrongly close the same eventfd file descriptor twice when taking down a connection channel after having completed a threaded name resolve. CVE-2025-0665 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:curl-8.14.1-150600.4.28.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:libcurl4-8.14.1-150600.4.28.1 moderate When libcurl is asked to perform automatic gzip decompression of content-encoded HTTP responses with the `CURLOPT_ACCEPT_ENCODING` option, **using zlib 1.2.0.3 or older**, an attacker-controlled integer overflow would make libcurl perform a buffer overflow. CVE-2025-0725 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:curl-8.14.1-150600.4.28.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:libcurl4-8.14.1-150600.4.28.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-15-sp6-chost-byos-v20250918-x86-64:curl-8.14.1-150600.4.28.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:libcurl4-8.14.1-150600.4.28.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Load DR6 with guest value only before entering .vcpu_run() loop Move the conditional loading of hardware DR6 with the guest's DR6 value out of the core .vcpu_run() loop to fix a bug where KVM can load hardware with a stale vcpu->arch.dr6. When the guest accesses a DR and host userspace isn't debugging the guest, KVM disables DR interception and loads the guest's values into hardware on VM-Enter and saves them on VM-Exit. This allows the guest to access DRs at will, e.g. so that a sequence of DR accesses to configure a breakpoint only generates one VM-Exit. For DR0-DR3, the logic/behavior is identical between VMX and SVM, and also identical between KVM_DEBUGREG_BP_ENABLED (userspace debugging the guest) and KVM_DEBUGREG_WONT_EXIT (guest using DRs), and so KVM handles loading DR0-DR3 in common code, _outside_ of the core kvm_x86_ops.vcpu_run() loop. But for DR6, the guest's value doesn't need to be loaded into hardware for KVM_DEBUGREG_BP_ENABLED, and SVM provides a dedicated VMCB field whereas VMX requires software to manually load the guest value, and so loading the guest's value into DR6 is handled by {svm,vmx}_vcpu_run(), i.e. is done _inside_ the core run loop. Unfortunately, saving the guest values on VM-Exit is initiated by common x86, again outside of the core run loop. If the guest modifies DR6 (in hardware, when DR interception is disabled), and then the next VM-Exit is a fastpath VM-Exit, KVM will reload hardware DR6 with vcpu->arch.dr6 and clobber the guest's actual value. The bug shows up primarily with nested VMX because KVM handles the VMX preemption timer in the fastpath, and the window between hardware DR6 being modified (in guest context) and DR6 being read by guest software is orders of magnitude larger in a nested setup. E.g. in non-nested, the VMX preemption timer would need to fire precisely between #DB injection and the #DB handler's read of DR6, whereas with a KVM-on-KVM setup, the window where hardware DR6 is "dirty" extends all the way from L1 writing DR6 to VMRESUME (in L1). L1's view: ========== <L1 disables DR interception> CPU 0/KVM-7289 [023] d.... 2925.640961: kvm_entry: vcpu 0 A: L1 Writes DR6 CPU 0/KVM-7289 [023] d.... 2925.640963: <hack>: Set DRs, DR6 = 0xffff0ff1 B: CPU 0/KVM-7289 [023] d.... 2925.640967: kvm_exit: vcpu 0 reason EXTERNAL_INTERRUPT intr_info 0x800000ec D: L1 reads DR6, arch.dr6 = 0 CPU 0/KVM-7289 [023] d.... 2925.640969: <hack>: Sync DRs, DR6 = 0xffff0ff0 CPU 0/KVM-7289 [023] d.... 2925.640976: kvm_entry: vcpu 0 L2 reads DR6, L1 disables DR interception CPU 0/KVM-7289 [023] d.... 2925.640980: kvm_exit: vcpu 0 reason DR_ACCESS info1 0x0000000000000216 CPU 0/KVM-7289 [023] d.... 2925.640983: kvm_entry: vcpu 0 CPU 0/KVM-7289 [023] d.... 2925.640983: <hack>: Set DRs, DR6 = 0xffff0ff0 L2 detects failure CPU 0/KVM-7289 [023] d.... 2925.640987: kvm_exit: vcpu 0 reason HLT L1 reads DR6 (confirms failure) CPU 0/KVM-7289 [023] d.... 2925.640990: <hack>: Sync DRs, DR6 = 0xffff0ff0 L0's view: ========== L2 reads DR6, arch.dr6 = 0 CPU 23/KVM-5046 [001] d.... 3410.005610: kvm_exit: vcpu 23 reason DR_ACCESS info1 0x0000000000000216 CPU 23/KVM-5046 [001] ..... 3410.005610: kvm_nested_vmexit: vcpu 23 reason DR_ACCESS info1 0x0000000000000216 L2 => L1 nested VM-Exit CPU 23/KVM-5046 [001] ..... 3410.005610: kvm_nested_vmexit_inject: reason: DR_ACCESS ext_inf1: 0x0000000000000216 CPU 23/KVM-5046 [001] d.... 3410.005610: kvm_entry: vcpu 23 CPU 23/KVM-5046 [001] d.... 3410.005611: kvm_exit: vcpu 23 reason VMREAD CPU 23/KVM-5046 [001] d.... 3410.005611: kvm_entry: vcpu 23 CPU 23/KVM-5046 [001] d.... 3410. ---truncated--- CVE-2025-21839 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: sockmap, vsock: For connectible sockets allow only connected sockmap expects all vsocks to have a transport assigned, which is expressed in vsock_proto::psock_update_sk_prot(). However, there is an edge case where an unconnected (connectible) socket may lose its previously assigned transport. This is handled with a NULL check in the vsock/BPF recv path. Another design detail is that listening vsocks are not supposed to have any transport assigned at all. Which implies they are not supported by the sockmap. But this is complicated by the fact that a socket, before switching to TCP_LISTEN, may have had some transport assigned during a failed connect() attempt. Hence, we may end up with a listening vsock in a sockmap, which blows up quickly: KASAN: null-ptr-deref in range [0x0000000000000120-0x0000000000000127] CPU: 7 UID: 0 PID: 56 Comm: kworker/7:0 Not tainted 6.14.0-rc1+ Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:vsock_read_skb+0x4b/0x90 Call Trace: sk_psock_verdict_data_ready+0xa4/0x2e0 virtio_transport_recv_pkt+0x1ca8/0x2acc vsock_loopback_work+0x27d/0x3f0 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x35a/0x700 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 For connectible sockets, instead of relying solely on the state of vsk->transport, tell sockmap to only allow those representing established connections. This aligns with the behaviour for AF_INET and AF_UNIX. CVE-2025-21854 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: efi: Don't map the entire mokvar table to determine its size Currently, when validating the mokvar table, we (re)map the entire table on each iteration of the loop, adding space as we discover new entries. If the table grows over a certain size, this fails due to limitations of early_memmap(), and we get a failure and traceback: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220 ... Call Trace: <TASK> ? __early_ioremap+0xef/0x220 ? __warn.cold+0x93/0xfa ? __early_ioremap+0xef/0x220 ? report_bug+0xff/0x140 ? early_fixup_exception+0x5d/0xb0 ? early_idt_handler_common+0x2f/0x3a ? __early_ioremap+0xef/0x220 ? efi_mokvar_table_init+0xce/0x1d0 ? setup_arch+0x864/0xc10 ? start_kernel+0x6b/0xa10 ? x86_64_start_reservations+0x24/0x30 ? x86_64_start_kernel+0xed/0xf0 ? common_startup_64+0x13e/0x141 </TASK> ---[ end trace 0000000000000000 ]--- mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187. Mapping the entire structure isn't actually necessary, as we don't ever need more than one entry header mapped at once. Changes efi_mokvar_table_init() to only map each entry header, not the entire table, when determining the table size. Since we're not mapping any data past the variable name, it also changes the code to enforce that each variable name is NUL terminated, rather than attempting to verify it in place. CVE-2025-21872 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range() If track_pfn_copy() fails, we already added the dst VMA to the maple tree. As fork() fails, we'll cleanup the maple tree, and stumble over the dst VMA for which we neither performed any reservation nor copied any page tables. Consequently untrack_pfn() will see VM_PAT and try obtaining the PAT information from the page table -- which fails because the page table was not copied. The easiest fix would be to simply clear the VM_PAT flag of the dst VMA if track_pfn_copy() fails. However, the whole thing is about "simply" clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy() and performed a reservation, but copying the page tables fails, we'll simply clear the VM_PAT flag, not properly undoing the reservation ... which is also wrong. So let's fix it properly: set the VM_PAT flag only if the reservation succeeded (leaving it clear initially), and undo the reservation if anything goes wrong while copying the page tables: clearing the VM_PAT flag after undoing the reservation. Note that any copied page table entries will get zapped when the VMA will get removed later, after copy_page_range() succeeded; as VM_PAT is not set then, we won't try cleaning VM_PAT up once more and untrack_pfn() will be happy. Note that leaving these page tables in place without a reservation is not a problem, as we are aborting fork(); this process will never run. A reproducer can trigger this usually at the first try: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 Modules linked in: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:get_pat_info+0xf6/0x110 ... Call Trace: <TASK> ... untrack_pfn+0x52/0x110 unmap_single_vma+0xa6/0xe0 unmap_vmas+0x105/0x1f0 exit_mmap+0xf6/0x460 __mmput+0x4b/0x120 copy_process+0x1bf6/0x2aa0 kernel_clone+0xab/0x440 __do_sys_clone+0x66/0x90 do_syscall_64+0x95/0x180 Likely this case was missed in: d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed") ... and instead of undoing the reservation we simply cleared the VM_PAT flag. Keep the documentation of these functions in include/linux/pgtable.h, one place is more than sufficient -- we should clean that up for the other functions like track_pfn_remap/untrack_pfn separately. CVE-2025-22090 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important 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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: dsa: clean up FDB, MDB, VLAN entries on unbind As explained in many places such as commit b117e1e8a86d ("net: dsa: delete dsa_legacy_fdb_add and dsa_legacy_fdb_del"), DSA is written given the assumption that higher layers have balanced additions/deletions. As such, it only makes sense to be extremely vocal when those assumptions are violated and the driver unbinds with entries still present. But Ido Schimmel points out a very simple situation where that is wrong: https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/ (also briefly discussed by me in the aforementioned commit). Basically, while the bridge bypass operations are not something that DSA explicitly documents, and for the majority of DSA drivers this API simply causes them to go to promiscuous mode, that isn't the case for all drivers. Some have the necessary requirements for bridge bypass operations to do something useful - see dsa_switch_supports_uc_filtering(). Although in tools/testing/selftests/net/forwarding/local_termination.sh, we made an effort to popularize better mechanisms to manage address filters on DSA interfaces from user space - namely macvlan for unicast, and setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, the fact is that 'bridge fdb add ... self static local' also exists as kernel UAPI, and might be useful to someone, even if only for a quick hack. It seems counter-productive to block that path by implementing shim .ndo_fdb_add and .ndo_fdb_del operations which just return -EOPNOTSUPP in order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() from running, although we could do that. Accepting that cleanup is necessary seems to be the only option. Especially since we appear to be coming back at this from a different angle as well. Russell King is noticing that the WARN_ON() triggers even for VLANs: https://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/ What happens in the bug report above is that dsa_port_do_vlan_del() fails, then the VLAN entry lingers on, and then we warn on unbind and leak it. This is not a straight revert of the blamed commit, but we now add an informational print to the kernel log (to still have a way to see that bugs exist), and some extra comments gathered from past years' experience, to justify the logic. CVE-2025-37864 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: crypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP() Herbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa implementation's ->key_size() callback returns an unusually large value. Herbert instead suggests (for a division by 8): X / 8 + !!(X & 7) Based on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and use it in lieu of DIV_ROUND_UP() for ->key_size() return values. Additionally, use the macro in ecc_digits_from_bytes(), whose "nbytes" parameter is a ->key_size() return value in some instances, or a user-specified ASN.1 length in the case of ecdsa_get_signature_rs(). CVE-2025-37984 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done Syzbot reported a slab-use-after-free with the following call trace: ================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25 Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394 Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done may still visit it in cryptd_queue_worker workqueue. I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1 The key of reproduction is that, simd_aead_encrypt is interrupted, leading to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is triggered, and the tipc_crypto tx will be visited. tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base; simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work) Fix this by holding net reference count before encrypt. CVE-2025-38052 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie The IOMMU translation for MSI message addresses has been a 2-step process, separated in time: 1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address is stored in the MSI descriptor when an MSI interrupt is allocated. 2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a translated message address. This has an inherent lifetime problem for the pointer stored in the cookie that must remain valid between the two steps. However, there is no locking at the irq layer that helps protect the lifetime. Today, this works under the assumption that the iommu domain is not changed while MSI interrupts being programmed. This is true for normal DMA API users within the kernel, as the iommu domain is attached before the driver is probed and cannot be changed while a driver is attached. Classic VFIO type1 also prevented changing the iommu domain while VFIO was running as it does not support changing the "container" after starting up. However, iommufd has improved this so that the iommu domain can be changed during VFIO operation. This potentially allows userspace to directly race VFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) and VFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()). This potentially causes both the cookie pointer and the unlocked call to iommu_get_domain_for_dev() on the MSI translation path to become UAFs. Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVA address is already known during iommu_dma_prepare_msi() and cannot change. Thus, it can simply be stored as an integer in the MSI descriptor. The other UAF related to iommu_get_domain_for_dev() will be addressed in patch "iommu: Make iommu_dma_prepare_msi() into a generic operation" by using the IOMMU group mutex. CVE-2025-38062 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: dm: fix unconditional IO throttle caused by REQ_PREFLUSH When a bio with REQ_PREFLUSH is submitted to dm, __send_empty_flush() generates a flush_bio with REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC, which causes the flush_bio to be throttled by wbt_wait(). An example from v5.4, similar problem also exists in upstream: crash> bt 2091206 PID: 2091206 TASK: ffff2050df92a300 CPU: 109 COMMAND: "kworker/u260:0" #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8 #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4 #2 [ffff800084a2f880] schedule at ffff800040bfa4b4 #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4 #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0 #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254 #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38 #8 [ffff800084a2fa60] generic_make_request at ffff800040570138 #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4 #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs] #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs] #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs] #13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs] #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs] #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs] #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08 #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc #18 [ffff800084a2fe70] kthread at ffff800040118de4 After commit 2def2845cc33 ("xfs: don't allow log IO to be throttled"), the metadata submitted by xlog_write_iclog() should not be throttled. But due to the existence of the dm layer, throttling flush_bio indirectly causes the metadata bio to be throttled. Fix this by conditionally adding REQ_IDLE to flush_bio.bi_opf, which makes wbt_should_throttle() return false to avoid wbt_wait(). CVE-2025-38063 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: unshare page tables during VMA split, not before Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split. Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked. An annoying detail is that we can now call into the helper hugetlb_unshare_pmds() from two different locking contexts: 1. from hugetlb_split(), holding: - mmap lock (exclusively) - VMA lock - file rmap lock (exclusively) 2. hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back. [jannh@google.com: v2] CVE-2025-38084 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race huge_pmd_unshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed. If this happens in the middle of a concurrent gup_fast(), gup_fast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected. Fix it with an explicit broadcast IPI through tlb_remove_table_sync_one(), just like we do in khugepaged when removing page tables for a THP collapse. CVE-2025-38085 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/sched: fix use-after-free in taprio_dev_notifier Since taprio's taprio_dev_notifier() isn't protected by an RCU read-side critical section, a race with advance_sched() can lead to a use-after-free. Adding rcu_read_lock() inside taprio_dev_notifier() prevents this. CVE-2025-38087 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv/memtrace: Fix out of bounds issue in memtrace mmap memtrace mmap issue has an out of bounds issue. This patch fixes the by checking that the requested mapping region size should stay within the allocated region size. CVE-2025-38088 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: sunrpc: handle SVC_GARBAGE during svc auth processing as auth error tianshuo han reported a remotely-triggerable crash if the client sends a kernel RPC server a specially crafted packet. If decoding the RPC reply fails in such a way that SVC_GARBAGE is returned without setting the rq_accept_statp pointer, then that pointer can be dereferenced and a value stored there. If it's the first time the thread has processed an RPC, then that pointer will be set to NULL and the kernel will crash. In other cases, it could create a memory scribble. The server sunrpc code treats a SVC_GARBAGE return from svc_authenticate or pg_authenticate as if it should send a GARBAGE_ARGS reply. RFC 5531 says that if authentication fails that the RPC should be rejected instead with a status of AUTH_ERR. Handle a SVC_GARBAGE return as an AUTH_ERROR, with a reason of AUTH_BADCRED instead of returning GARBAGE_ARGS in that case. This sidesteps the whole problem of touching the rpc_accept_statp pointer in this situation and avoids the crash. CVE-2025-38089 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: drivers/rapidio/rio_cm.c: prevent possible heap overwrite In riocm_cdev_ioctl(RIO_CM_CHAN_SEND) -> cm_chan_msg_send() -> riocm_ch_send() cm_chan_msg_send() checks that userspace didn't send too much data but riocm_ch_send() failed to check that userspace sent sufficient data. The result is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr which were outside the bounds of the space which cm_chan_msg_send() allocated. Address this by teaching riocm_ch_send() to check that the entire rio_ch_chan_hdr was copied in from userspace. CVE-2025-38090 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: dma-buf: insert memory barrier before updating num_fences smp_store_mb() inserts memory barrier after storing operation. It is different with what the comment is originally aiming so Null pointer dereference can be happened if memory update is reordered. CVE-2025-38095 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: espintcp: remove encap socket caching to avoid reference leak The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns. The reference chain is: xfrm_state -> enacp_sk -> netns Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket. This patch results in a small (~2% in my tests) performance regression. A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used "recently", but it's a lot more complex than just not caching the socket. CVE-2025-38097 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Don't treat wb connector as physical in create_validate_stream_for_sink Don't try to operate on a drm_wb_connector as an amdgpu_dm_connector. While dereferencing aconnector->base will "work" it's wrong and might lead to unknown bad things. Just... don't. CVE-2025-38098 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/broken A SCO connection without the proper voice_setting can cause the controller to lock up. CVE-2025-38099 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: x86/iopl: Cure TIF_IO_BITMAP inconsistencies io_bitmap_exit() is invoked from exit_thread() when a task exists or when a fork fails. In the latter case the exit_thread() cleans up resources which were allocated during fork(). io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the current task. If current has TIF_IO_BITMAP set, but no bitmap installed, tss_update_io_bitmap() crashes with a NULL pointer dereference. There are two issues, which lead to that problem: 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork(). 2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated. This happens when a kernel thread is created in the context of a user space thread, which has TIF_IO_BITMAP set as the thread flags are copied and the IO bitmap pointer is cleared. Other than in the failed fork() case this has no impact because kernel threads including IO workers never return to user space and therefore never invoke tss_update_io_bitmap(). Cure this by adding the missing cleanups and checks: 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task. 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share(). For paranoia sake, add a warning into tss_update_io_bitmap() to catch the case, when that code is invoked with inconsistent state. CVE-2025-38100 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate 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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: net_sched: ets: fix a race in ets_qdisc_change() Gerrard Tai reported a race condition in ETS, 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-38107 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix ECVF vports unload on shutdown flow Fix shutdown flow UAF when a virtual function is created on the embedded chip (ECVF) of a BlueField device. In such case the vport acl ingress table is not properly destroyed. ECVF functionality is independent of ecpf_vport_exists capability and thus functions mlx5_eswitch_(enable|disable)_pf_vf_vports() should not test it when enabling/disabling ECVF vports. kernel log: [] refcount_t: underflow; use-after-free. [] WARNING: CPU: 3 PID: 1 at lib/refcount.c:28 refcount_warn_saturate+0x124/0x220 ---------------- [] Call trace: [] refcount_warn_saturate+0x124/0x220 [] tree_put_node+0x164/0x1e0 [mlx5_core] [] mlx5_destroy_flow_table+0x98/0x2c0 [mlx5_core] [] esw_acl_ingress_table_destroy+0x28/0x40 [mlx5_core] [] esw_acl_ingress_lgcy_cleanup+0x80/0xf4 [mlx5_core] [] esw_legacy_vport_acl_cleanup+0x44/0x60 [mlx5_core] [] esw_vport_cleanup+0x64/0x90 [mlx5_core] [] mlx5_esw_vport_disable+0xc0/0x1d0 [mlx5_core] [] mlx5_eswitch_unload_ec_vf_vports+0xcc/0x150 [mlx5_core] [] mlx5_eswitch_disable_sriov+0x198/0x2a0 [mlx5_core] [] mlx5_device_disable_sriov+0xb8/0x1e0 [mlx5_core] [] mlx5_sriov_detach+0x40/0x50 [mlx5_core] [] mlx5_unload+0x40/0xc4 [mlx5_core] [] mlx5_unload_one_devl_locked+0x6c/0xe4 [mlx5_core] [] mlx5_unload_one+0x3c/0x60 [mlx5_core] [] shutdown+0x7c/0xa4 [mlx5_core] [] pci_device_shutdown+0x3c/0xa0 [] device_shutdown+0x170/0x340 [] __do_sys_reboot+0x1f4/0x2a0 [] __arm64_sys_reboot+0x2c/0x40 [] invoke_syscall+0x78/0x100 [] el0_svc_common.constprop.0+0x54/0x184 [] do_el0_svc+0x30/0xac [] el0_svc+0x48/0x160 [] el0t_64_sync_handler+0xa4/0x12c [] el0t_64_sync+0x1a4/0x1a8 [] --[ end trace 9c4601d68c70030e ]--- CVE-2025-38109 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: net/mdiobus: Fix potential out-of-bounds clause 45 read/write access When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via C45 (clause 45) mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write. Fix that by adding address verification before C45 read/write operation. While this excludes this access from any statistics, it improves security of read/write operation. CVE-2025-38110 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: net/mdiobus: Fix potential out-of-bounds read/write access When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write. Fix that by adding address verification before read/write operation. While this excludes this access from any statistics, it improves security of read/write operation. CVE-2025-38111 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important 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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Fix NULL pointer dereference when nosmp is used With nosmp in cmdline, other CPUs are not brought up, leaving their cpc_desc_ptr NULL. CPU0's iteration via for_each_possible_cpu() dereferences these NULL pointers, causing panic. Panic backtrace: [ 0.401123] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b8 ... [ 0.403255] [<ffffffff809a5818>] cppc_allow_fast_switch+0x6a/0xd4 ... Kernel panic - not syncing: Attempted to kill init! [ rjw: New subject ] CVE-2025-38113 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete This reworks MGMT_OP_REMOVE_ADV_MONITOR to not use mgmt_pending_add to avoid crashes like bellow: ================================================================== BUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406 Read of size 8 at addr ffff88801c53f318 by task kworker/u5:5/5341 CPU: 0 UID: 0 PID: 5341 Comm: kworker/u5:5 Not tainted 6.15.0-syzkaller-10402-g4cb6c8af8591 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: hci0 hci_cmd_sync_work 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 mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406 hci_cmd_sync_work+0x261/0x3a0 net/bluetooth/hci_sync.c:334 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x711/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> Allocated by task 5987: 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:4358 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] mgmt_pending_new+0x65/0x240 net/bluetooth/mgmt_util.c:252 mgmt_pending_add+0x34/0x120 net/bluetooth/mgmt_util.c:279 remove_adv_monitor+0x103/0x1b0 net/bluetooth/mgmt.c:5454 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x548/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 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 Freed by task 5989: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2380 [inline] slab_free mm/slub.c:4642 [inline] kfree+0x18e/0x440 mm/slub.c:4841 mgmt_pending_foreach+0xc9/0x120 net/bluetooth/mgmt_util.c:242 mgmt_index_removed+0x10d/0x2f0 net/bluetooth/mgmt.c:9366 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314 __sys_bind_socket net/socket.c:1810 [inline] __sys_bind+0x2c3/0x3e0 net/socket.c:1841 __do_sys_bind net/socket.c:1846 [inline] __se_sys_bind net/socket.c:1844 [inline] __x64_sys_bind+0x7a/0x90 net/socket.c:1844 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 CVE-2025-38118 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important 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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: Fix napi rx poll issue When driver handles the napi rx polling requests, the netdev might have been released by the dellink logic triggered by the disconnect operation on user plane. However, in the logic of processing skb in polling, an invalid netdev is still being used, which causes a panic. BUG: kernel NULL pointer dereference, address: 00000000000000f1 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:dev_gro_receive+0x3a/0x620 [...] Call Trace: <IRQ> ? __die_body+0x68/0xb0 ? page_fault_oops+0x379/0x3e0 ? exc_page_fault+0x4f/0xa0 ? asm_exc_page_fault+0x22/0x30 ? __pfx_t7xx_ccmni_recv_skb+0x10/0x10 [mtk_t7xx (HASH:1400 7)] ? dev_gro_receive+0x3a/0x620 napi_gro_receive+0xad/0x170 t7xx_ccmni_recv_skb+0x48/0x70 [mtk_t7xx (HASH:1400 7)] t7xx_dpmaif_napi_rx_poll+0x590/0x800 [mtk_t7xx (HASH:1400 7)] net_rx_action+0x103/0x470 irq_exit_rcu+0x13a/0x310 sysvec_apic_timer_interrupt+0x56/0x90 </IRQ> CVE-2025-38123 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: fix udp gso skb_segment after pull from frag_list Commit a1e40ac5b5e9 ("net: gso: fix udp gso fraglist segmentation after pull from frag_list") detected invalid geometry in frag_list skbs and redirects them from skb_segment_list to more robust skb_segment. But some packets with modified geometry can also hit bugs in that code. We don't know how many such cases exist. Addressing each one by one also requires touching the complex skb_segment code, which risks introducing bugs for other types of skbs. Instead, linearize all these packets that fail the basic invariants on gso fraglist skbs. That is more robust. If only part of the fraglist payload is pulled into head_skb, it will always cause exception when splitting skbs by skb_segment. For detailed call stack information, see below. Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify fraglist skbs, breaking these invariants. In extreme cases they pull one part of data into skb linear. For UDP, this causes three payloads with lengths of (11,11,10) bytes were pulled tail to become (12,10,10) bytes. The skbs no longer meets the above SKB_GSO_FRAGLIST conditions because payload was pulled into head_skb, it needs to be linearized before pass to regular skb_segment. skb_segment+0xcd0/0xd14 __udp_gso_segment+0x334/0x5f4 udp4_ufo_fragment+0x118/0x15c inet_gso_segment+0x164/0x338 skb_mac_gso_segment+0xc4/0x13c __skb_gso_segment+0xc4/0x124 validate_xmit_skb+0x9c/0x2c0 validate_xmit_skb_list+0x4c/0x80 sch_direct_xmit+0x70/0x404 __dev_queue_xmit+0x64c/0xe5c neigh_resolve_output+0x178/0x1c4 ip_finish_output2+0x37c/0x47c __ip_finish_output+0x194/0x240 ip_finish_output+0x20/0xf4 ip_output+0x100/0x1a0 NF_HOOK+0xc4/0x16c ip_forward+0x314/0x32c ip_rcv+0x90/0x118 __netif_receive_skb+0x74/0x124 process_backlog+0xe8/0x1a4 __napi_poll+0x5c/0x1f8 net_rx_action+0x154/0x314 handle_softirqs+0x154/0x4b8 [118.376811] [C201134] rxq0_pus: [name:bug&]kernel BUG at net/core/skbuff.c:4278! [118.376829] [C201134] rxq0_pus: [name:traps&]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [118.470774] [C201134] rxq0_pus: [name:mrdump&]Kernel Offset: 0x178cc00000 from 0xffffffc008000000 [118.470810] [C201134] rxq0_pus: [name:mrdump&]PHYS_OFFSET: 0x40000000 [118.470827] [C201134] rxq0_pus: [name:mrdump&]pstate: 60400005 (nZCv daif +PAN -UAO) [118.470848] [C201134] rxq0_pus: [name:mrdump&]pc : [0xffffffd79598aefc] skb_segment+0xcd0/0xd14 [118.470900] [C201134] rxq0_pus: [name:mrdump&]lr : [0xffffffd79598a5e8] skb_segment+0x3bc/0xd14 [118.470928] [C201134] rxq0_pus: [name:mrdump&]sp : ffffffc008013770 CVE-2025-38124 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: ice: fix Tx scheduler error handling in XDP callback When the XDP program is loaded, the XDP callback adds new Tx queues. This means that the callback must update the Tx scheduler with the new queue number. In the event of a Tx scheduler failure, the XDP callback should also fail and roll back any changes previously made for XDP preparation. The previous implementation had a bug that not all changes made by the XDP callback were rolled back. This caused the crash with the following call trace: [ +9.549584] ice 0000:ca:00.0: Failed VSI LAN queue config for XDP, error: -5 [ +0.382335] Oops: general protection fault, probably for non-canonical address 0x50a2250a90495525: 0000 [#1] SMP NOPTI [ +0.010710] CPU: 103 UID: 0 PID: 0 Comm: swapper/103 Not tainted 6.14.0-net-next-mar-31+ #14 PREEMPT(voluntary) [ +0.010175] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022 [ +0.010946] RIP: 0010:__ice_update_sample+0x39/0xe0 [ice] [...] [ +0.002715] Call Trace: [ +0.002452] <IRQ> [ +0.002021] ? __die_body.cold+0x19/0x29 [ +0.003922] ? die_addr+0x3c/0x60 [ +0.003319] ? exc_general_protection+0x17c/0x400 [ +0.004707] ? asm_exc_general_protection+0x26/0x30 [ +0.004879] ? __ice_update_sample+0x39/0xe0 [ice] [ +0.004835] ice_napi_poll+0x665/0x680 [ice] [ +0.004320] __napi_poll+0x28/0x190 [ +0.003500] net_rx_action+0x198/0x360 [ +0.003752] ? update_rq_clock+0x39/0x220 [ +0.004013] handle_softirqs+0xf1/0x340 [ +0.003840] ? sched_clock_cpu+0xf/0x1f0 [ +0.003925] __irq_exit_rcu+0xc2/0xe0 [ +0.003665] common_interrupt+0x85/0xa0 [ +0.003839] </IRQ> [ +0.002098] <TASK> [ +0.002106] asm_common_interrupt+0x26/0x40 [ +0.004184] RIP: 0010:cpuidle_enter_state+0xd3/0x690 Fix this by performing the missing unmapping of XDP queues from q_vectors and setting the XDP rings pointer back to NULL after all those queues are released. Also, add an immediate exit from the XDP callback in case of ring preparation failure. CVE-2025-38127 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: page_pool: Fix use-after-free in page_pool_recycle_in_ring syzbot reported a uaf in page_pool_recycle_in_ring: BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943 CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline] _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline] page_pool_recycle_in_ring net/core/page_pool.c:707 [inline] page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826 page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline] page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline] napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036 skb_pp_recycle net/core/skbuff.c:1047 [inline] skb_free_head net/core/skbuff.c:1094 [inline] skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125 skb_release_all net/core/skbuff.c:1190 [inline] __kfree_skb net/core/skbuff.c:1204 [inline] sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242 kfree_skb_reason include/linux/skbuff.h:1263 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline] root cause is: page_pool_recycle_in_ring ptr_ring_produce spin_lock(&r->producer_lock); WRITE_ONCE(r->queue[r->producer++], ptr) //recycle last page to pool page_pool_release page_pool_scrub page_pool_empty_ring ptr_ring_consume page_pool_return_page //release all page __page_pool_destroy free_percpu(pool->recycle_stats); free(pool) //free spin_unlock(&r->producer_lock); //pool->ring uaf read recycle_stat_inc(pool, ring); page_pool can be free while page pool recycle the last page in ring. Add producer-lock barrier to page_pool_release to prevent the page pool from being free before all pages have been recycled. recycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is not enabled, which will trigger Wempty-body build warning. Add definition for pool stat macro to fix warning. CVE-2025-38129 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: coresight: prevent deactivate active config while enabling the config While enable active config via cscfg_csdev_enable_active_config(), active config could be deactivated via configfs' sysfs interface. This could make UAF issue in below scenario: CPU0 CPU1 (sysfs enable) load module cscfg_load_config_sets() activate config. // sysfs (sys_active_cnt == 1) ... cscfg_csdev_enable_active_config() lock(csdev->cscfg_csdev_lock) // here load config activate by CPU1 unlock(csdev->cscfg_csdev_lock) deactivate config // sysfs (sys_activec_cnt == 0) cscfg_unload_config_sets() unload module // access to config_desc which freed // while unloading module. cscfg_csdev_enable_config To address this, use cscfg_config_desc's active_cnt as a reference count which will be holded when - activate the config. - enable the activated config. and put the module reference when config_active_cnt == 0. CVE-2025-38131 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: coresight: holding cscfg_csdev_lock while removing cscfg from csdev There'll be possible race scenario for coresight config: CPU0 CPU1 (perf enable) load module cscfg_load_config_sets() activate config. // sysfs (sys_active_cnt == 1) ... cscfg_csdev_enable_active_config() lock(csdev->cscfg_csdev_lock) deactivate config // sysfs (sys_activec_cnt == 0) cscfg_unload_config_sets() <iterating config_csdev_list> cscfg_remove_owned_csdev_configs() // here load config activate by CPU1 unlock(csdev->cscfg_csdev_lock) iterating config_csdev_list could be raced with config_csdev_list's entry delete. To resolve this race , hold csdev->cscfg_csdev_lock() while cscfg_remove_owned_csdev_configs() CVE-2025-38132 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: serial: Fix potential null-ptr-deref in mlb_usio_probe() devm_ioremap() can return NULL on error. Currently, mlb_usio_probe() does not check for this case, which could result in a NULL pointer dereference. Add NULL check after devm_ioremap() to prevent this issue. CVE-2025-38135 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Reorder clock handling and power management in probe Reorder the initialization sequence in `usbhs_probe()` to enable runtime PM before accessing registers, preventing potential crashes due to uninitialized clocks. Currently, in the probe path, registers are accessed before enabling the clocks, leading to a synchronous external abort on the RZ/V2H SoC. The problematic call flow is as follows: usbhs_probe() usbhs_sys_clock_ctrl() usbhs_bset() usbhs_write() iowrite16() <-- Register access before enabling clocks Since `iowrite16()` is performed without ensuring the required clocks are enabled, this can lead to access errors. To fix this, enable PM runtime early in the probe function and ensure clocks are acquired before register access, preventing crashes like the following on RZ/V2H: [13.272640] Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP [13.280814] Modules linked in: cec renesas_usbhs(+) drm_kms_helper fuse drm backlight ipv6 [13.289088] CPU: 1 UID: 0 PID: 195 Comm: (udev-worker) Not tainted 6.14.0-rc7+ #98 [13.296640] Hardware name: Renesas RZ/V2H EVK Board based on r9a09g057h44 (DT) [13.303834] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [13.310770] pc : usbhs_bset+0x14/0x4c [renesas_usbhs] [13.315831] lr : usbhs_probe+0x2e4/0x5ac [renesas_usbhs] [13.321138] sp : ffff8000827e3850 [13.324438] x29: ffff8000827e3860 x28: 0000000000000000 x27: ffff8000827e3ca0 [13.331554] x26: ffff8000827e3ba0 x25: ffff800081729668 x24: 0000000000000025 [13.338670] x23: ffff0000c0f08000 x22: 0000000000000000 x21: ffff0000c0f08010 [13.345783] x20: 0000000000000000 x19: ffff0000c3b52080 x18: 00000000ffffffff [13.352895] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000827e36ce [13.360009] x14: 00000000000003d7 x13: 00000000000003d7 x12: 0000000000000000 [13.367122] x11: 0000000000000000 x10: 0000000000000aa0 x9 : ffff8000827e3750 [13.374235] x8 : ffff0000c1850b00 x7 : 0000000003826060 x6 : 000000000000001c [13.381347] x5 : 000000030d5fcc00 x4 : ffff8000825c0000 x3 : 0000000000000000 [13.388459] x2 : 0000000000000400 x1 : 0000000000000000 x0 : ffff0000c3b52080 [13.395574] Call trace: [13.398013] usbhs_bset+0x14/0x4c [renesas_usbhs] (P) [13.403076] platform_probe+0x68/0xdc [13.406738] really_probe+0xbc/0x2c0 [13.410306] __driver_probe_device+0x78/0x120 [13.414653] driver_probe_device+0x3c/0x154 [13.418825] __driver_attach+0x90/0x1a0 [13.422647] bus_for_each_dev+0x7c/0xe0 [13.426470] driver_attach+0x24/0x30 [13.430032] bus_add_driver+0xe4/0x208 [13.433766] driver_register+0x68/0x130 [13.437587] __platform_driver_register+0x24/0x30 [13.442273] renesas_usbhs_driver_init+0x20/0x1000 [renesas_usbhs] [13.448450] do_one_initcall+0x60/0x1d4 [13.452276] do_init_module+0x54/0x1f8 [13.456014] load_module+0x1754/0x1c98 [13.459750] init_module_from_file+0x88/0xcc [13.464004] __arm64_sys_finit_module+0x1c4/0x328 [13.468689] invoke_syscall+0x48/0x104 [13.472426] el0_svc_common.constprop.0+0xc0/0xe0 [13.477113] do_el0_svc+0x1c/0x28 [13.480415] el0_svc+0x30/0xcc [13.483460] el0t_64_sync_handler+0x10c/0x138 [13.487800] el0t_64_sync+0x198/0x19c [13.491453] Code: 2a0103e1 12003c42 12003c63 8b010084 (79400084) [13.497522] ---[ end trace 0000000000000000 ]--- CVE-2025-38136 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: Add NULL check in udma_probe() devm_kasprintf() returns NULL when memory allocation fails. Currently, udma_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. CVE-2025-38138 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: hwmon: (asus-ec-sensors) check sensor index in read_string() Prevent a potential invalid memory access when the requested sensor is not found. find_ec_sensor_index() may return a negative value (e.g. -ENOENT), but its result was used without checking, which could lead to undefined behavior when passed to get_sensor_info(). Add a proper check to return -EINVAL if sensor_index is negative. Found by Linux Verification Center (linuxtesting.org) with SVACE. [groeck: Return error code returned from find_ec_sensor_index] CVE-2025-38142 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: backlight: pm8941: Add NULL check in wled_configure() devm_kasprintf() returns NULL when memory allocation fails. Currently, wled_configure() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. CVE-2025-38143 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: soc: aspeed: Add NULL check in aspeed_lpc_enable_snoop() devm_kasprintf() returns NULL when memory allocation fails. Currently, aspeed_lpc_enable_snoop() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. [arj: Fix Fixes: tag to use subject from 3772e5da4454] CVE-2025-38145 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: phy: mscc: Fix memory leak when using one step timestamping Fix memory leak when running one-step timestamping. When running one-step sync timestamping, the HW is configured to insert the TX time into the frame, so there is no reason to keep the skb anymore. As in this case the HW will never generate an interrupt to say that the frame was timestamped, then the frame will never released. Fix this by freeing the frame in case of one-step timestamping. CVE-2025-38148 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: phy: clear phydev->devlink when the link is deleted There is a potential crash issue when disabling and re-enabling the network port. When disabling the network port, phy_detach() calls device_link_del() to remove the device link, but it does not clear phydev->devlink, so phydev->devlink is not a NULL pointer. Then the network port is re-enabled, but if phy_attach_direct() fails before calling device_link_add(), the code jumps to the "error" label and calls phy_detach(). Since phydev->devlink retains the old value from the previous attach/detach cycle, device_link_del() uses the old value, which accesses a NULL pointer and causes a crash. The simplified crash log is as follows. [ 24.702421] Call trace: [ 24.704856] device_link_put_kref+0x20/0x120 [ 24.709124] device_link_del+0x30/0x48 [ 24.712864] phy_detach+0x24/0x168 [ 24.716261] phy_attach_direct+0x168/0x3a4 [ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c [ 24.725140] phylink_of_phy_connect+0x1c/0x34 Therefore, phydev->devlink needs to be cleared when the device link is deleted. CVE-2025-38149 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Fix hang when cma_netevent_callback fails to queue_work The cited commit fixed a crash when cma_netevent_callback was called for a cma_id while work on that id from a previous call had not yet started. The work item was re-initialized in the second call, which corrupted the work item currently in the work queue. However, it left a problem when queue_work fails (because the item is still pending in the work queue from a previous call). In this case, cma_id_put (which is called in the work handler) is therefore not called. This results in a userspace process hang (zombie process). Fix this by calling cma_id_put() if queue_work fails. CVE-2025-38151 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Avoid using sk_socket after free when sending The sk->sk_socket is not locked or referenced in backlog thread, and during the call to skb_send_sock(), there is a race condition with the release of sk_socket. All types of sockets(tcp/udp/unix/vsock) will be affected. Race conditions: ''' CPU0 CPU1 backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here ''' The ref of psock become 0 after sock_map_close() executed. ''' void sock_map_close() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ... } ''' Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions. With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work. If no backlog running, any pending work that hasn't started by then will fail when invoked by sk_psock_get(), as the psock reference count have been zeroed, and sk_psock_drop() will cancel all jobs via cancel_delayed_work_sync(). In summary, we require synchronization to coordinate the backlog thread and close() thread. The panic I catched: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: <TASK> ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... ''' CVE-2025-38154 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init() devm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference. Prevent null pointer dereference in mt7915_mmio_wed_init(). CVE-2025-38155 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: hisi_acc_vfio_pci: fix XQE dma address error The dma addresses of EQE and AEQE are wrong after migration and results in guest kernel-mode encryption services failure. Comparing the definition of hardware registers, we found that there was an error when the data read from the register was combined into an address. Therefore, the address combination sequence needs to be corrected. Even after fixing the above problem, we still have an issue where the Guest from an old kernel can get migrated to new kernel and may result in wrong data. In order to ensure that the address is correct after migration, if an old magic number is detected, the dma address needs to be updated. CVE-2025-38158 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds Set the size to 6 instead of 2, since 'para' array is passed to 'rtw_fw_bt_wifi_control(rtwdev, para[0], &para[1])', which reads 5 bytes: void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data) { ... SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data); SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1)); ... SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4)); Detected using the static analysis tool - Svace. CVE-2025-38159 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important 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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: prevent overflow in lookup table allocation When calculating the lookup table size, ensure the following multiplication does not overflow: - desc->field_len[] maximum value is U8_MAX multiplied by NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case. - NFT_PIPAPO_BUCKETS(f->bb) is 2^8, worst case. - sizeof(unsigned long), from sizeof(*f->lt), lt in struct nft_pipapo_field. Then, use check_mul_overflow() to multiply by bucket size and then use check_add_overflow() to the alignment for avx2 (if needed). Finally, add lt_size_check_overflow() helper and use it to consolidate this. While at it, replace leftover allocation using the GFP_KERNEL to GFP_KERNEL_ACCOUNT for consistency, in pipapo_resize(). CVE-2025-38162 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: ublk: santizize the arguments from userspace when adding a device Sanity check the values for queue depth and number of queues we get from userspace when adding a device. CVE-2025-38182 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: lan743x: fix potential out-of-bounds write in lan743x_ptp_io_event_clock_get() Before calling lan743x_ptp_io_event_clock_get(), the 'channel' value is checked against the maximum value of PCI11X1X_PTP_IO_MAX_CHANNELS(8). This seems correct and aligns with the PTP interrupt status register (PTP_INT_STS) specifications. However, lan743x_ptp_io_event_clock_get() writes to ptp->extts[] with only LAN743X_PTP_N_EXTTS(4) elements, using channel as an index: lan743x_ptp_io_event_clock_get(..., u8 channel,...) { ... /* Update Local timestamp */ extts = &ptp->extts[channel]; extts->ts.tv_sec = sec; ... } To avoid an out-of-bounds write and utilize all the supported GPIO inputs, set LAN743X_PTP_N_EXTTS to 8. Detected using the static analysis tool - Svace. CVE-2025-38183 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. [ Rebase onto Blackwell changes. - Danilo ] CVE-2025-38187 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm/a7xx: Call CP_RESET_CONTEXT_STATE Calling this packet is necessary when we switch contexts because there are various pieces of state used by userspace to synchronize between BR and BV that are persistent across submits and we need to make sure that they are in a "safe" state when switching contexts. Otherwise a userspace submission in one context could cause another context to function incorrectly and hang, effectively a denial of service (although without leaking data). This was missed during initial a7xx bringup. Patchwork: https://patchwork.freedesktop.org/patch/654924/ CVE-2025-38188 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: jffs2: check that raw node were preallocated before writing summary Syzkaller detected a kernel bug in jffs2_link_node_ref, caused by fault injection in jffs2_prealloc_raw_node_refs. jffs2_sum_write_sumnode doesn't check return value of jffs2_prealloc_raw_node_refs and simply lets any error propagate into jffs2_sum_write_data, which eventually calls jffs2_link_node_ref in order to link the summary to an expectedly allocated node. kernel BUG at fs/jffs2/nodelist.c:592! invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 31277 Comm: syz-executor.7 Not tainted 6.1.128-syzkaller-00139-ge10f83ca10a1 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2_link_node_ref+0x570/0x690 fs/jffs2/nodelist.c:592 Call Trace: <TASK> jffs2_sum_write_data fs/jffs2/summary.c:841 [inline] jffs2_sum_write_sumnode+0xd1a/0x1da0 fs/jffs2/summary.c:874 jffs2_do_reserve_space+0xa18/0xd60 fs/jffs2/nodemgmt.c:388 jffs2_reserve_space+0x55f/0xaa0 fs/jffs2/nodemgmt.c:197 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362 jffs2_write_end+0x726/0x15d0 fs/jffs2/file.c:301 generic_perform_write+0x314/0x5d0 mm/filemap.c:3856 __generic_file_write_iter+0x2ae/0x4d0 mm/filemap.c:3973 generic_file_write_iter+0xe3/0x350 mm/filemap.c:4005 call_write_iter include/linux/fs.h:2265 [inline] do_iter_readv_writev+0x20f/0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c:763 [inline] direct_splice_actor+0x10c/0x170 fs/splice.c:950 splice_direct_to_actor+0x337/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Fix this issue by checking return value of jffs2_prealloc_raw_node_refs before calling jffs2_sum_write_data. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. CVE-2025-38194 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell_rbu: Fix list usage Pass the correct list head to list_for_each_entry*() when looping through the packet list. Without this patch, reading the packet data via sysfs will show the data incorrectly (because it starts at the wrong packet), and clearing the packet list will result in a NULL pointer dereference. CVE-2025-38197 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem() bpf_map_lookup_percpu_elem() helper is also available for sleepable bpf program. When BPF JIT is disabled or under 32-bit host, bpf_map_lookup_percpu_elem() will not be inlined. Using it in a sleepable bpf program will trigger the warning in bpf_map_lookup_percpu_elem(), because the bpf program only holds rcu_read_lock_trace lock. Therefore, add the missed check. CVE-2025-38202 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: jfs: Fix null-ptr-deref in jfs_ioc_trim [ Syzkaller Report ] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000087: 0000 [#1 KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f] CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted 6.13.0-rc6-gfbfd64d25c7a-dirty #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Sched_ext: serialise (enabled+all), task: runnable_at=-30ms RIP: 0010:jfs_ioc_trim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __die_body+0x61/0xb0 ? die_addr+0xb1/0xe0 ? exc_general_protection+0x333/0x510 ? asm_exc_general_protection+0x26/0x30 ? jfs_ioc_trim+0x34b/0x8f0 jfs_ioctl+0x3c8/0x4f0 ? __pfx_jfs_ioctl+0x10/0x10 ? __pfx_jfs_ioctl+0x10/0x10 __se_sys_ioctl+0x269/0x350 ? __pfx___se_sys_ioctl+0x10/0x10 ? do_syscall_64+0xfb/0x210 do_syscall_64+0xee/0x210 ? syscall_exit_to_user_mode+0x1e0/0x330 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe51f4903ad Code: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d RSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903ad RDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640 R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:jfs_ioc_trim+0x34b/0x8f0 Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 93 90 82 fe ff 4c 89 ff 31 f6 RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206 RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000a RDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001 RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000 R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438 FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Kernel panic - not syncing: Fatal exception [ Analysis ] We believe that we have found a concurrency bug in the `fs/jfs` module that results in a null pointer dereference. There is a closely related issue which has been fixed: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234 ... but, unfortunately, the accepted patch appears to still be susceptible to a null pointer dereference under some interleavings. To trigger the bug, we think that `JFS_SBI(ipbmap->i_sb)->bmap` is set to NULL in `dbFreeBits` and then dereferenced in `jfs_ioc_trim`. This bug manifests quite rarely under normal circumstances, but is triggereable from a syz-program. CVE-2025-38203 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds read in add_missing_indices stbl is s8 but it must contain offsets into slot which can go from 0 to 127. Added a bound check for that error and return -EIO if the check fails. Also make jfs_readdir return with error if add_missing_indices returns with an error. CVE-2025-38204 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: exfat: fix double free in delayed_free The double free could happen in the following path. exfat_create_upcase_table() exfat_create_upcase_table() : return error exfat_free_upcase_table() : free ->vol_utbl exfat_load_default_upcase_table : return error exfat_kill_sb() delayed_free() exfat_free_upcase_table() <--------- double free This patch set ->vol_util as NULL after freeing it. CVE-2025-38206 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: configfs-tsm-report: Fix NULL dereference of tsm_ops Unlike sysfs, the lifetime of configfs objects is controlled by userspace. There is no mechanism for the kernel to find and delete all created config-items. Instead, the configfs-tsm-report mechanism has an expectation that tsm_unregister() can happen at any time and cause established config-item access to start failing. That expectation is not fully satisfied. While tsm_report_read(), tsm_report_{is,is_bin}_visible(), and tsm_report_make_item() safely fail if tsm_ops have been unregistered, tsm_report_privlevel_store() tsm_report_provider_show() fail to check for ops registration. Add the missing checks for tsm_ops having been removed. Now, in supporting the ability for tsm_unregister() to always succeed, it leaves the problem of what to do with lingering config-items. The expectation is that the admin that arranges for the ->remove() (unbind) of the ${tsm_arch}-guest driver is also responsible for deletion of all open config-items. Until that deletion happens, ->probe() (reload / bind) of the ${tsm_arch}-guest driver fails. This allows for emergency shutdown / revocation of attestation interfaces, and requires coordinated restart. CVE-2025-38210 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2025-38213 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var If fb_add_videomode() in do_register_framebuffer() fails to allocate memory for fb_videomode, it will later 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 ================================================================ Even though fbcon_init() checks beforehand if fb_match_mode() in var_to_display() fails, it can not prevent the panic because fbcon_init() does not return error code. Considering this and the comment in the code about fb_match_mode() returning NULL - "This should not happen" - it is better to prevent registering the fb_info if its mode was not set successfully. Also move fb_add_videomode() closer to the beginning of do_register_framebuffer() to avoid having to do the cleanup on fail. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. CVE-2025-38215 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: hwmon: (ftsteutates) Fix TOCTOU race in fts_read() In the fts_read() function, when handling hwmon_pwm_auto_channels_temp, the code accesses the shared variable data->fan_source[channel] twice without holding any locks. It is first checked against FTS_FAN_SOURCE_INVALID, and if the check passes, it is read again when used as an argument to the BIT() macro. This creates a Time-of-Check to Time-of-Use (TOCTOU) race condition. Another thread executing fts_update_device() can modify the value of data->fan_source[channel] between the check and its use. If the value is changed to FTS_FAN_SOURCE_INVALID (0xff) during this window, the BIT() macro will be called with a large shift value (BIT(255)). A bit shift by a value greater than or equal to the type width is undefined behavior and can lead to a crash or incorrect values being returned to userspace. Fix this by reading data->fan_source[channel] into a local variable once, eliminating the race condition. Additionally, add a bounds check to ensure the value is less than BITS_PER_LONG before passing it to the BIT() macro, making the code more robust against undefined behavior. This possible bug was found by an experimental static analysis tool developed by our team. CVE-2025-38217 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: ext4: only dirty folios when data journaling regular files fstest generic/388 occasionally reproduces a crash that looks as follows: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: <TASK> ext4_block_zero_page_range+0x30c/0x380 [ext4] ext4_truncate+0x436/0x440 [ext4] ext4_process_orphan+0x5d/0x110 [ext4] ext4_orphan_cleanup+0x124/0x4f0 [ext4] ext4_fill_super+0x262d/0x3110 [ext4] get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x26/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4ed/0x6b0 do_syscall_64+0x82/0x170 ... This occurs when processing a symlink inode from the orphan list. The partial block zeroing code in the truncate path calls ext4_dirty_journalled_data() -> folio_mark_dirty(). The latter calls mapping->a_ops->dirty_folio(), but symlink inodes are not assigned an a_ops vector in ext4, hence the crash. To avoid this problem, update the ext4_dirty_journalled_data() helper to only mark the folio dirty on regular files (for which a_ops is assigned). This also matches the journaling logic in the ext4_symlink() creation path, where ext4_handle_dirty_metadata() is called directly. CVE-2025-38220 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Cleanup after an allocation error When allocation failures are not cleaned up by the driver, further allocation errors will be false-positives, which will cause buffers to remain uninitialized and cause NULL pointer dereferences. Ensure proper cleanup of failed allocations to prevent these issues. CVE-2025-38225 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: media: vivid: Change the siize of the composing syzkaller found a bug: BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline] BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705 Write of size 1440 at addr ffffc9000d0ffda0 by task vivid-000-vid-c/5304 CPU: 0 UID: 0 PID: 5304 Comm: vivid-000-vid-c Not tainted 6.14.0-rc2-syzkaller-00039-g09fbf3d50205 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline] tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705 vivid_fillbuff drivers/media/test-drivers/vivid/vivid-kthread-cap.c:470 [inline] vivid_thread_vid_cap_tick+0xf8e/0x60d0 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:629 vivid_thread_vid_cap+0x8aa/0xf30 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:767 kthread+0x7a9/0x920 kernel/kthread.c:464 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> The composition size cannot be larger than the size of fmt_cap_rect. So execute v4l2_rect_map_inside() even if has_compose_cap == 0. CVE-2025-38226 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: media: vidtv: Terminating the subsequent process of initialization failure syzbot reported a slab-use-after-free Read in vidtv_mux_init. [1] After PSI initialization fails, the si member is accessed again, resulting in this uaf. After si initialization fails, the subsequent process needs to be exited. [1] BUG: KASAN: slab-use-after-free in vidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78 [inline] BUG: KASAN: slab-use-after-free in vidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524 Read of size 8 at addr ffff88802fa42acc by task syz.2.37/6059 CPU: 0 UID: 0 PID: 6059 Comm: syz.2.37 Not tainted 6.14.0-rc5-syzkaller #0 Hardware name: 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+0xd9/0x110 mm/kasan/report.c:634 vidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78 vidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239 dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973 dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline] dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537 dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3ff/0xb70 fs/file_table.c:464 task_work_run+0x14e/0x250 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xad8/0x2d70 kernel/exit.c:938 do_group_exit+0xd3/0x2a0 kernel/exit.c:1087 __do_sys_exit_group kernel/exit.c:1098 [inline] __se_sys_exit_group kernel/exit.c:1096 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1096 x64_sys_call+0x151f/0x1720 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f871d58d169 Code: Unable to access opcode bytes at 0x7f871d58d13f. RSP: 002b:00007fff4b19a788 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f871d58d169 RDX: 0000000000000064 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00007fff4b19a7ec R08: 0000000b4b19a87f R09: 00000000000927c0 R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000003 R13: 00000000000927c0 R14: 000000000001d553 R15: 00007fff4b19a840 </TASK> Allocated by task 6059: 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 kmalloc_noprof include/linux/slab.h:901 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] vidtv_psi_pat_table_init drivers/media/test-drivers/vidtv/vidtv_psi.c:970 vidtv_channel_si_init drivers/media/test-drivers/vidtv/vidtv_channel.c:423 vidtv_mux_init drivers/media/test-drivers/vidtv/vidtv_mux.c:519 vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194 vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239 dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973 dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline] dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537 dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3ff/0xb70 fs/file_tabl ---truncated--- CVE-2025-38227 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: media: cxusb: no longer judge rbuf when the write fails syzbot reported a uninit-value in cxusb_i2c_xfer. [1] Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw() succeeds and rlen is greater than 0, the read operation of usb_bulk_msg() will be executed to read rlen bytes of data from the dvb device into the rbuf. In this case, although rlen is 1, the write operation failed which resulted in the dvb read operation not being executed, and ultimately variable i was not initialized. [1] BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343 i2c_master_send include/linux/i2c.h:109 [inline] i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183 do_loop_readv_writev fs/read_write.c:848 [inline] vfs_writev+0x963/0x14e0 fs/read_write.c:1057 do_writev+0x247/0x5c0 fs/read_write.c:1101 __do_sys_writev fs/read_write.c:1169 [inline] __se_sys_writev fs/read_write.c:1166 [inline] __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f CVE-2025-38229 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfsd: Initialize ssc before laundromat_work to prevent NULL dereference In nfs4_state_start_net(), laundromat_work may access nfsd_ssc through nfs4_laundromat -> nfsd4_ssc_expire_umount. If nfsd_ssc isn't initialized, this can cause NULL pointer dereference. Normally the delayed start of laundromat_work allows sufficient time for nfsd_ssc initialization to complete. However, when the kernel waits too long for userspace responses (e.g. in nfs4_state_start_net -> nfsd4_end_grace -> nfsd4_record_grace_done -> nfsd4_cld_grace_done -> cld_pipe_upcall -> __cld_pipe_upcall -> wait_for_completion path), the delayed work may start before nfsd_ssc initialization finishes. Fix this by moving nfsd_ssc initialization before starting laundromat_work. CVE-2025-38231 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: af_unix: Don't leave consecutive consumed OOB skbs. Jann Horn reported a use-after-free in unix_stream_read_generic(). The following sequences reproduce the issue: $ python3 from socket import * s1, s2 = socketpair(AF_UNIX, SOCK_STREAM) s1.send(b'x', MSG_OOB) s2.recv(1, MSG_OOB) # leave a consumed OOB skb s1.send(b'y', MSG_OOB) s2.recv(1, MSG_OOB) # leave a consumed OOB skb s1.send(b'z', MSG_OOB) s2.recv(1) # recv 'z' illegally s2.recv(1, MSG_OOB) # access 'z' skb (use-after-free) Even though a user reads OOB data, the skb holding the data stays on the recv queue to mark the OOB boundary and break the next recv(). After the last send() in the scenario above, the sk2's recv queue has 2 leading consumed OOB skbs and 1 real OOB skb. Then, the following happens during the next recv() without MSG_OOB 1. unix_stream_read_generic() peeks the first consumed OOB skb 2. manage_oob() returns the next consumed OOB skb 3. unix_stream_read_generic() fetches the next not-yet-consumed OOB skb 4. unix_stream_read_generic() reads and frees the OOB skb , and the last recv(MSG_OOB) triggers KASAN splat. The 3. above occurs because of the SO_PEEK_OFF code, which does not expect unix_skb_len(skb) to be 0, but this is true for such consumed OOB skbs. while (skip >= unix_skb_len(skb)) { skip -= unix_skb_len(skb); skb = skb_peek_next(skb, &sk->sk_receive_queue); ... } In addition to this use-after-free, there is another issue that ioctl(SIOCATMARK) does not function properly with consecutive consumed OOB skbs. So, nothing good comes out of such a situation. Instead of complicating manage_oob(), ioctl() handling, and the next ECONNRESET fix by introducing a loop for consecutive consumed OOB skbs, let's not leave such consecutive OOB unnecessarily. Now, while receiving an OOB skb in unix_stream_recv_urg(), if its previous skb is a consumed OOB skb, it is freed. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor (net/unix/af_unix.c:3027) Read of size 4 at addr ffff888106ef2904 by task python3/315 CPU: 2 UID: 0 PID: 315 Comm: python3 Not tainted 6.16.0-rc1-00407-gec315832f6f9 #8 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:409 mm/kasan/report.c:521) kasan_report (mm/kasan/report.c:636) unix_stream_read_actor (net/unix/af_unix.c:3027) unix_stream_read_generic (net/unix/af_unix.c:2708 net/unix/af_unix.c:2847) unix_stream_recvmsg (net/unix/af_unix.c:3048) sock_recvmsg (net/socket.c:1063 (discriminator 20) net/socket.c:1085 (discriminator 20)) __sys_recvfrom (net/socket.c:2278) __x64_sys_recvfrom (net/socket.c:2291 (discriminator 1) net/socket.c:2287 (discriminator 1) net/socket.c:2287 (discriminator 1)) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f8911fcea06 Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08 RSP: 002b:00007fffdb0dccb0 EFLAGS: 00000202 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007fffdb0dcdc8 RCX: 00007f8911fcea06 RDX: 0000000000000001 RSI: 00007f8911a5e060 RDI: 0000000000000006 RBP: 00007fffdb0dccd0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000202 R12: 00007f89119a7d20 R13: ffffffffc4653600 R14: 0000000000000000 R15: 0000000000000000 </TASK> Allocated by task 315: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1)) __kasan_slab_alloc (mm/kasan/common.c:348) kmem_cache_alloc_ ---truncated--- CVE-2025-38236 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: scsi: megaraid_sas: Fix invalid node index On a system with DRAM interleave enabled, out-of-bound access is detected: megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0 ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x46/0x4b megasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas] megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas] local_pci_probe+0x42/0x90 pci_device_probe+0xdc/0x290 really_probe+0xdb/0x340 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8b/0xe0 bus_add_driver+0x142/0x220 driver_register+0x72/0xd0 megasas_init+0xdf/0xff0 [megaraid_sas] do_one_initcall+0x57/0x310 do_init_module+0x90/0x250 init_module_from_file+0x85/0xc0 idempotent_init_module+0x114/0x310 __x64_sys_finit_module+0x65/0xc0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it accordingly. CVE-2025-38239 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential deadlock when reconnecting channels Fix cifs_signal_cifsd_for_reconnect() to take the correct lock order and prevent the following deadlock from happening ====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc3-build2+ #1301 Tainted: G S W ------------------------------------------------------ cifsd/6055 is trying to acquire lock: ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200 but task is already holding lock: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&ret_buf->chan_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_setup_session+0x81/0x4b0 cifs_get_smb_ses+0x771/0x900 cifs_mount_get_session+0x7e/0x170 cifs_mount+0x92/0x2d0 cifs_smb3_do_mount+0x161/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&ret_buf->ses_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_match_super+0x101/0x320 sget+0xab/0x270 cifs_smb3_do_mount+0x1e0/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}: check_noncircular+0x95/0xc0 check_prev_add+0x115/0x2f0 validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_signal_cifsd_for_reconnect+0x134/0x200 __cifs_reconnect+0x8f/0x500 cifs_handle_standard+0x112/0x280 cifs_demultiplex_thread+0x64d/0xbc0 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30 other info that might help us debug this: Chain exists of: &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ret_buf->chan_lock); lock(&ret_buf->ses_lock); lock(&ret_buf->chan_lock); lock(&tcp_ses->srv_lock); *** DEADLOCK *** 3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200 #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200 #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200 CVE-2025-38244 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: bnxt: properly flush XDP redirect lists We encountered following crash when testing a XDP_REDIRECT feature in production: [56251.579676] list_add corruption. next->prev should be prev (ffff93120dd40f30), but was ffffb301ef3a6740. (next=ffff93120dd 40f30). [56251.601413] ------------[ cut here ]------------ [56251.611357] kernel BUG at lib/list_debug.c:29! [56251.621082] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [56251.632073] CPU: 111 UID: 0 PID: 0 Comm: swapper/111 Kdump: loaded Tainted: P O 6.12.33-cloudflare-2025.6. 3 #1 [56251.653155] Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE [56251.663877] Hardware name: MiTAC GC68B-B8032-G11P6-GPU/S8032GM-HE-CFR, BIOS V7.020.B10-sig 01/22/2025 [56251.682626] RIP: 0010:__list_add_valid_or_report+0x4b/0xa0 [56251.693203] Code: 0e 48 c7 c7 68 e7 d9 97 e8 42 16 fe ff 0f 0b 48 8b 52 08 48 39 c2 74 14 48 89 f1 48 c7 c7 90 e7 d9 97 48 89 c6 e8 25 16 fe ff <0f> 0b 4c 8b 02 49 39 f0 74 14 48 89 d1 48 c7 c7 e8 e7 d9 97 4c 89 [56251.725811] RSP: 0018:ffff93120dd40b80 EFLAGS: 00010246 [56251.736094] RAX: 0000000000000075 RBX: ffffb301e6bba9d8 RCX: 0000000000000000 [56251.748260] RDX: 0000000000000000 RSI: ffff9149afda0b80 RDI: ffff9149afda0b80 [56251.760349] RBP: ffff9131e49c8000 R08: 0000000000000000 R09: ffff93120dd40a18 [56251.772382] R10: ffff9159cf2ce1a8 R11: 0000000000000003 R12: ffff911a80850000 [56251.784364] R13: ffff93120fbc7000 R14: 0000000000000010 R15: ffff9139e7510e40 [56251.796278] FS: 0000000000000000(0000) GS:ffff9149afd80000(0000) knlGS:0000000000000000 [56251.809133] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [56251.819561] CR2: 00007f5e85e6f300 CR3: 00000038b85e2006 CR4: 0000000000770ef0 [56251.831365] PKRU: 55555554 [56251.838653] Call Trace: [56251.845560] <IRQ> [56251.851943] cpu_map_enqueue.cold+0x5/0xa [56251.860243] xdp_do_redirect+0x2d9/0x480 [56251.868388] bnxt_rx_xdp+0x1d8/0x4c0 [bnxt_en] [56251.877028] bnxt_rx_pkt+0x5f7/0x19b0 [bnxt_en] [56251.885665] ? cpu_max_write+0x1e/0x100 [56251.893510] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.902276] __bnxt_poll_work+0x190/0x340 [bnxt_en] [56251.911058] bnxt_poll+0xab/0x1b0 [bnxt_en] [56251.919041] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.927568] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.935958] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.944250] __napi_poll+0x2b/0x160 [56251.951155] bpf_trampoline_6442548651+0x79/0x123 [56251.959262] __napi_poll+0x5/0x160 [56251.966037] net_rx_action+0x3d2/0x880 [56251.973133] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.981265] ? srso_alias_return_thunk+0x5/0xfbef5 [56251.989262] ? __hrtimer_run_queues+0x162/0x2a0 [56251.996967] ? srso_alias_return_thunk+0x5/0xfbef5 [56252.004875] ? srso_alias_return_thunk+0x5/0xfbef5 [56252.012673] ? bnxt_msix+0x62/0x70 [bnxt_en] [56252.019903] handle_softirqs+0xcf/0x270 [56252.026650] irq_exit_rcu+0x67/0x90 [56252.032933] common_interrupt+0x85/0xa0 [56252.039498] </IRQ> [56252.044246] <TASK> [56252.048935] asm_common_interrupt+0x26/0x40 [56252.055727] RIP: 0010:cpuidle_enter_state+0xb8/0x420 [56252.063305] Code: dc 01 00 00 e8 f9 79 3b ff e8 64 f7 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 a5 32 3a ff 45 84 ff 0f 85 ae 01 00 00 fb 45 85 f6 <0f> 88 88 01 00 00 48 8b 04 24 49 63 ce 4c 89 ea 48 6b f1 68 48 29 [56252.088911] RSP: 0018:ffff93120c97fe98 EFLAGS: 00000202 [56252.096912] RAX: ffff9149afd80000 RBX: ffff9141d3a72800 RCX: 0000000000000000 [56252.106844] RDX: 00003329176c6b98 RSI: ffffffe36db3fdc7 RDI: 0000000000000000 [56252.116733] RBP: 0000000000000002 R08: 0000000000000002 R09: 000000000000004e [56252.126652] R10: ffff9149afdb30c4 R11: 071c71c71c71c71c R12: ffffffff985ff860 [56252.136637] R13: 00003329176c6b98 R14: 0000000000000002 R15: 0000000000000000 [56252.146667] ? cpuidle_enter_state+0xab/0x420 [56252.153909] cpuidle_enter+0x2d/0x40 [56252.160360] do_idle+0x176/0x1c0 [56252.166456 ---truncated--- CVE-2025-38246 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: bridge: mcast: Fix use-after-free during router port configuration The bridge maintains a global list of ports behind which a multicast router resides. The list is consulted during forwarding to ensure multicast packets are forwarded to these ports even if the ports are not member in the matching MDB entry. When per-VLAN multicast snooping is enabled, the per-port multicast context is disabled on each port and the port is removed from the global router port list: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 # ip link add name dummy1 up master br1 type dummy # ip link set dev dummy1 type bridge_slave mcast_router 2 $ bridge -d mdb show | grep router router ports on br1: dummy1 # ip link set dev br1 type bridge mcast_vlan_snooping 1 $ bridge -d mdb show | grep router However, the port can be re-added to the global list even when per-VLAN multicast snooping is enabled: # ip link set dev dummy1 type bridge_slave mcast_router 0 # ip link set dev dummy1 type bridge_slave mcast_router 2 $ bridge -d mdb show | grep router router ports on br1: dummy1 Since commit 4b30ae9adb04 ("net: bridge: mcast: re-implement br_multicast_{enable, disable}_port functions"), when per-VLAN multicast snooping is enabled, multicast disablement on a port will disable the per-{port, VLAN} multicast contexts and not the per-port one. As a result, a port will remain in the global router port list even after it is deleted. This will lead to a use-after-free [1] when the list is traversed (when adding a new port to the list, for example): # ip link del dev dummy1 # ip link add name dummy2 up master br1 type dummy # ip link set dev dummy2 type bridge_slave mcast_router 2 Similarly, stale entries can also be found in the per-VLAN router port list. When per-VLAN multicast snooping is disabled, the per-{port, VLAN} contexts are disabled on each port and the port is removed from the per-VLAN router port list: # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1 # ip link add name dummy1 up master br1 type dummy # bridge vlan add vid 2 dev dummy1 # bridge vlan global set vid 2 dev br1 mcast_snooping 1 # bridge vlan set vid 2 dev dummy1 mcast_router 2 $ bridge vlan global show dev br1 vid 2 | grep router router ports: dummy1 # ip link set dev br1 type bridge mcast_vlan_snooping 0 $ bridge vlan global show dev br1 vid 2 | grep router However, the port can be re-added to the per-VLAN list even when per-VLAN multicast snooping is disabled: # bridge vlan set vid 2 dev dummy1 mcast_router 0 # bridge vlan set vid 2 dev dummy1 mcast_router 2 $ bridge vlan global show dev br1 vid 2 | grep router router ports: dummy1 When the VLAN is deleted from the port, the per-{port, VLAN} multicast context will not be disabled since multicast snooping is not enabled on the VLAN. As a result, the port will remain in the per-VLAN router port list even after it is no longer member in the VLAN. This will lead to a use-after-free [2] when the list is traversed (when adding a new port to the list, for example): # ip link add name dummy2 up master br1 type dummy # bridge vlan add vid 2 dev dummy2 # bridge vlan del vid 2 dev dummy1 # bridge vlan set vid 2 dev dummy2 mcast_router 2 Fix these issues by removing the port from the relevant (global or per-VLAN) router port list in br_multicast_port_ctx_deinit(). The function is invoked during port deletion with the per-port multicast context and during VLAN deletion with the per-{port, VLAN} multicast context. Note that deleting the multicast router timer is not enough as it only takes care of the temporary multicast router states (1 or 3) and not the permanent one (2). [1] BUG: KASAN: slab-out-of-bounds in br_multicast_add_router.part.0+0x3f1/0x560 Write of size 8 at addr ffff888004a67328 by task ip/384 [...] Call Trace: <TASK> dump_stack ---truncated--- CVE-2025-38248 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: s390/pkey: Prevent overflow in size calculation for memdup_user() Number of apqn target list entries contained in 'nr_apqns' variable is determined by userspace via an ioctl call so the result of the product in calculation of size passed to memdup_user() may overflow. In this case the actual size of the allocated area and the value describing it won't be in sync leading to various types of unpredictable behaviour later. Use a proper memdup_array_user() helper which returns an error if an overflow is detected. Note that it is different from when nr_apqns is initially zero - that case is considered valid and should be handled in subsequent pkey_handler implementations. Found by Linux Verification Center (linuxtesting.org). CVE-2025-38257 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd9335: Fix missing free of regulator supplies Driver gets and enables all regulator supplies in probe path (wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanup in final error paths and in unbind (missing remove() callback). This leads to leaked memory and unbalanced regulator enable count during probe errors or unbind. Fix this by converting entire code into devm_regulator_bulk_get_enable() which also greatly simplifies the code. CVE-2025-38259 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: net: dsa: b53: do not enable EEE on bcm63xx BCM63xx internal switches do not support EEE, but provide multiple RGMII ports where external PHYs may be connected. If one of these PHYs are EEE capable, we may try to enable EEE for the MACs, which then hangs the system on access of the (non-existent) EEE registers. Fix this by checking if the switch actually supports EEE before attempting to configure it. CVE-2025-38272 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp-usb: Fix an NULL vs IS_ERR() bug The qmp_usb_iomap() helper function currently returns the raw result of devm_ioremap() for non-exclusive mappings. Since devm_ioremap() may return a NULL pointer and the caller only checks error pointers with IS_ERR(), NULL could bypass the check and lead to an invalid dereference. Fix the issue by checking if devm_ioremap() returns NULL. When it does, qmp_usb_iomap() now returns an error pointer via IOMEM_ERR_PTR(-ENOMEM), ensuring safe and consistent error handling. CVE-2025-38275 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: mtd: nand: ecc-mxic: Fix use of uninitialized variable ret If ctx->steps is zero, the loop processing ECC steps is skipped, and the variable ret remains uninitialized. It is later checked and returned, which leads to undefined behavior and may cause unpredictable results in user space or kernel crashes. This scenario can be triggered in edge cases such as misconfigured geometry, ECC engine misuse, or if ctx->steps is not validated after initialization. Initialize ret to zero before the loop to ensure correct and safe behavior regardless of the ctx->steps value. Found by Linux Verification Center (linuxtesting.org) with SVACE. CVE-2025-38277 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: bpf: Do not include stack ptr register in precision backtracking bookkeeping Yi Lai reported an issue ([1]) where the following warning appears in kernel dmesg: [ 60.643604] verifier backtracking bug [ 60.643635] WARNING: CPU: 10 PID: 2315 at kernel/bpf/verifier.c:4302 __mark_chain_precision+0x3a6c/0x3e10 [ 60.648428] Modules linked in: bpf_testmod(OE) [ 60.650471] CPU: 10 UID: 0 PID: 2315 Comm: test_progs Tainted: G OE 6.15.0-rc4-gef11287f8289-dirty #327 PREEMPT(full) [ 60.654385] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [ 60.656682] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 60.660475] RIP: 0010:__mark_chain_precision+0x3a6c/0x3e10 [ 60.662814] Code: 5a 30 84 89 ea e8 c4 d9 01 00 80 3d 3e 7d d8 04 00 0f 85 60 fa ff ff c6 05 31 7d d8 04 01 48 c7 c7 00 58 30 84 e8 c4 06 a5 ff <0f> 0b e9 46 fa ff ff 48 ... [ 60.668720] RSP: 0018:ffff888116cc7298 EFLAGS: 00010246 [ 60.671075] RAX: 54d70e82dfd31900 RBX: ffff888115b65e20 RCX: 0000000000000000 [ 60.673659] RDX: 0000000000000001 RSI: 0000000000000004 RDI: 00000000ffffffff [ 60.676241] RBP: 0000000000000400 R08: ffff8881f6f23bd3 R09: 1ffff1103ede477a [ 60.678787] R10: dffffc0000000000 R11: ffffed103ede477b R12: ffff888115b60ae8 [ 60.681420] R13: 1ffff11022b6cbc4 R14: 00000000fffffff2 R15: 0000000000000001 [ 60.684030] FS: 00007fc2aedd80c0(0000) GS:ffff88826fa8a000(0000) knlGS:0000000000000000 [ 60.686837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 60.689027] CR2: 000056325369e000 CR3: 000000011088b002 CR4: 0000000000370ef0 [ 60.691623] Call Trace: [ 60.692821] <TASK> [ 60.693960] ? __pfx_verbose+0x10/0x10 [ 60.695656] ? __pfx_disasm_kfunc_name+0x10/0x10 [ 60.697495] check_cond_jmp_op+0x16f7/0x39b0 [ 60.699237] do_check+0x58fa/0xab10 ... Further analysis shows the warning is at line 4302 as below: 4294 /* static subprog call instruction, which 4295 * means that we are exiting current subprog, 4296 * so only r1-r5 could be still requested as 4297 * precise, r0 and r6-r10 or any stack slot in 4298 * the current frame should be zero by now 4299 */ 4300 if (bt_reg_mask(bt) & ~BPF_REGMASK_ARGS) { 4301 verbose(env, "BUG regs %x\n", bt_reg_mask(bt)); 4302 WARN_ONCE(1, "verifier backtracking bug"); 4303 return -EFAULT; 4304 } With the below test (also in the next patch): __used __naked static void __bpf_jmp_r10(void) { asm volatile ( "r2 = 2314885393468386424 ll;" "goto +0;" "if r2 <= r10 goto +3;" "if r1 >= -1835016 goto +0;" "if r2 <= 8 goto +0;" "if r3 <= 0 goto +0;" "exit;" ::: __clobber_all); } SEC("?raw_tp") __naked void bpf_jmp_r10(void) { asm volatile ( "r3 = 0 ll;" "call __bpf_jmp_r10;" "r0 = 0;" "exit;" ::: __clobber_all); } The following is the verifier failure log: 0: (18) r3 = 0x0 ; R3_w=0 2: (85) call pc+2 caller: R10=fp0 callee: frame1: R1=ctx() R3_w=0 R10=fp0 5: frame1: R1=ctx() R3_w=0 R10=fp0 ; asm volatile (" \ @ verifier_precision.c:184 5: (18) r2 = 0x20202000256c6c78 ; frame1: R2_w=0x20202000256c6c78 7: (05) goto pc+0 8: (bd) if r2 <= r10 goto pc+3 ; frame1: R2_w=0x20202000256c6c78 R10=fp0 9: (35) if r1 >= 0xffe3fff8 goto pc+0 ; frame1: R1=ctx() 10: (b5) if r2 <= 0x8 goto pc+0 mark_precise: frame1: last_idx 10 first_idx 0 subseq_idx -1 mark_precise: frame1: regs=r2 stack= before 9: (35) if r1 >= 0xffe3fff8 goto pc+0 mark_precise: frame1: regs=r2 stack= before 8: (bd) if r2 <= r10 goto pc+3 mark_preci ---truncated--- CVE-2025-38279 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: hisi_acc_vfio_pci: bugfix live migration function without VF device driver If the VF device driver is not loaded in the Guest OS and we attempt to perform device data migration, the address of the migrated data will be NULL. The live migration recovery operation on the destination side will access a null address value, which will cause access errors. Therefore, live migration of VMs without added VF device drivers does not require device data migration. In addition, when the queue address data obtained by the destination is empty, device queue recovery processing will not be performed. CVE-2025-38283 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: pinctrl: at91: Fix possible out-of-boundary access at91_gpio_probe() doesn't check that given OF alias is not available or something went wrong when trying to get it. This might have consequences when accessing gpio_chips array with that value as an index. Note, that BUG() can be compiled out and hence won't actually perform the required checks. CVE-2025-38286 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Avoid potential ndlp use-after-free in dev_loss_tmo_callbk Smatch detected a potential use-after-free of an ndlp oject in dev_loss_tmo_callbk during driver unload or fatal error handling. Fix by reordering code to avoid potential use-after-free if initial nodelist reference has been previously removed. CVE-2025-38289 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix node corruption in ar->arvifs list In current WLAN recovery code flow, ath12k_core_halt() only reinitializes the "arvifs" list head. This will cause the list node immediately following the list head to become an invalid list node. Because the prev of that node still points to the list head "arvifs", but the next of the list head "arvifs" no longer points to that list node. When a WLAN recovery occurs during the execution of a vif removal, and it happens before the spin_lock_bh(&ar->data_lock) in ath12k_mac_vdev_delete(), list_del() will detect the previously mentioned situation, thereby triggering a kernel panic. The fix is to remove and reinitialize all vif list nodes from the list head "arvifs" during WLAN halt. The reinitialization is to make the list nodes valid, ensuring that the list_del() in ath12k_mac_vdev_delete() can execute normally. Call trace: __list_del_entry_valid_or_report+0xd4/0x100 (P) ath12k_mac_remove_link_interface.isra.0+0xf8/0x2e4 [ath12k] ath12k_scan_vdev_clean_work+0x40/0x164 [ath12k] cfg80211_wiphy_work+0xfc/0x100 process_one_work+0x164/0x2d0 worker_thread+0x254/0x380 kthread+0xfc/0x100 ret_from_fork+0x10/0x20 The change is mostly copied from the ath11k patch: https://lore.kernel.org/all/20250320053145.3445187-1-quic_stonez@quicinc.com/ Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 CVE-2025-38290 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix invalid access to memory In ath12k_dp_rx_msdu_coalesce(), rxcb is fetched from skb and boolean is_continuation is part of rxcb. Currently, after freeing the skb, the rxcb->is_continuation accessed again which is wrong since the memory is already freed. This might lead use-after-free error. Hence, fix by locally defining bool is_continuation from rxcb, so that after freeing skb, is_continuation can be used. Compile tested only. CVE-2025-38292 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix node corruption in ar->arvifs list In current WLAN recovery code flow, ath11k_core_halt() only reinitializes the "arvifs" list head. This will cause the list node immediately following the list head to become an invalid list node. Because the prev of that node still points to the list head "arvifs", but the next of the list head "arvifs" no longer points to that list node. When a WLAN recovery occurs during the execution of a vif removal, and it happens before the spin_lock_bh(&ar->data_lock) in ath11k_mac_op_remove_interface(), list_del() will detect the previously mentioned situation, thereby triggering a kernel panic. The fix is to remove and reinitialize all vif list nodes from the list head "arvifs" during WLAN halt. The reinitialization is to make the list nodes valid, ensuring that the list_del() in ath11k_mac_op_remove_interface() can execute normally. Call trace: __list_del_entry_valid_or_report+0xb8/0xd0 ath11k_mac_op_remove_interface+0xb0/0x27c [ath11k] drv_remove_interface+0x48/0x194 [mac80211] ieee80211_do_stop+0x6e0/0x844 [mac80211] ieee80211_stop+0x44/0x17c [mac80211] __dev_close_many+0xac/0x150 __dev_change_flags+0x194/0x234 dev_change_flags+0x24/0x6c devinet_ioctl+0x3a0/0x670 inet_ioctl+0x200/0x248 sock_do_ioctl+0x60/0x118 sock_ioctl+0x274/0x35c __arm64_sys_ioctl+0xac/0xf0 invoke_syscall+0x48/0x114 ... Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 CVE-2025-38293 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare() Fix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare(): 1] If dma_map_sg() fails for areq->dst, the device driver would try to free DMA memory it has not allocated in the first place. To fix this, on the "theend_sgs" error path, call dma unmap only if the corresponding dma map was successful. 2] If the dma_map_single() call for the IV fails, the device driver would try to free an invalid DMA memory address on the "theend_iv" path: ------------[ cut here ]------------ DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90 Modules linked in: skcipher_example(O+) CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G O 6.15.0-rc3+ #24 PREEMPT Tainted: [O]=OOT_MODULE Hardware name: OrangePi Zero2 (DT) pc : check_unmap+0x123c/0x1b90 lr : check_unmap+0x123c/0x1b90 ... Call trace: check_unmap+0x123c/0x1b90 (P) debug_dma_unmap_page+0xac/0xc0 dma_unmap_page_attrs+0x1f4/0x5fc sun8i_ce_cipher_do_one+0x1bd4/0x1f40 crypto_pump_work+0x334/0x6e0 kthread_worker_fn+0x21c/0x438 kthread+0x374/0x664 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- To fix this, check for !dma_mapping_error() before calling dma_unmap_single() on the "theend_iv" path. CVE-2025-38300 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: eir: Fix possible crashes on eir_create_adv_data eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER without checking if that would fit. CVE-2025-38303 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix NULL pointer deference on eir_get_service_data The len parameter is considered optional so it can be NULL so it cannot be used for skipping to next entry of EIR_SERVICE_DATA. CVE-2025-38304 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use() There is no disagreement that we should check both ptp->is_virtual_clock and ptp->n_vclocks to check if the ptp virtual clock is in use. However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in ptp_vclock_in_use(), we observe a recursive lock in the call trace starting from n_vclocks_store(). ============================================ WARNING: possible recursive locking detected 6.15.0-rc6 #1 Not tainted -------------------------------------------- syz.0.1540/13807 is trying to acquire lock: ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline] ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415 but task is already holding lock: ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** DEADLOCK *** .... ============================================ The best way to solve this is to remove the logic that checks ptp->n_vclocks in ptp_vclock_in_use(). The reason why this is appropriate is that any path that uses ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater than 0 before unregistering vclocks, and all functions are already written this way. And in the function that uses ptp->n_vclocks, we already get ptp->n_vclocks_mux before unregistering vclocks. Therefore, we need to remove the redundant check for ptp->n_vclocks in ptp_vclock_in_use() to prevent recursive locking. CVE-2025-38305 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: avs: Verify content returned by parse_int_array() The first element of the returned array stores its length. If it is 0, any manipulation beyond the element at index 0 ends with null-ptr-deref. CVE-2025-38307 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: seg6: Fix validation of nexthop addresses The kernel currently validates that the length of the provided nexthop address does not exceed the specified length. This can lead to the kernel reading uninitialized memory if user space provided a shorter length than the specified one. Fix by validating that the provided length exactly matches the specified one. CVE-2025-38310 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: aoe: clean device rq_list in aoedev_downdev() An aoe device's rq_list contains accepted block requests that are waiting to be transmitted to the aoe target. This queue was added as part of the conversion to blk_mq. However, the queue was not cleaned out when an aoe device is downed which caused blk_mq_freeze_queue() to sleep indefinitely waiting for those requests to complete, causing a hang. This fix cleans out the queue before calling blk_mq_freeze_queue(). CVE-2025-38326 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: jffs2: check jffs2_prealloc_raw_node_refs() result in few other places Fuzzing hit another invalid pointer dereference due to the lack of checking whether jffs2_prealloc_raw_node_refs() completed successfully. Subsequent logic implies that the node refs have been allocated. Handle that. The code is ready for propagating the error upwards. KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 PID: 5835 Comm: syz-executor145 Not tainted 5.10.234-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2_link_node_ref+0xac/0x690 fs/jffs2/nodelist.c:600 Call Trace: jffs2_mark_erased_block fs/jffs2/erase.c:460 [inline] jffs2_erase_pending_blocks+0x688/0x1860 fs/jffs2/erase.c:118 jffs2_garbage_collect_pass+0x638/0x1a00 fs/jffs2/gc.c:253 jffs2_reserve_space+0x3f4/0xad0 fs/jffs2/nodemgmt.c:167 jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362 jffs2_write_end+0x712/0x1110 fs/jffs2/file.c:302 generic_perform_write+0x2c2/0x500 mm/filemap.c:3347 __generic_file_write_iter+0x252/0x610 mm/filemap.c:3465 generic_file_write_iter+0xdb/0x230 mm/filemap.c:3497 call_write_iter include/linux/fs.h:2039 [inline] do_iter_readv_writev+0x46d/0x750 fs/read_write.c:740 do_iter_write+0x18c/0x710 fs/read_write.c:866 vfs_writev+0x1db/0x6a0 fs/read_write.c:939 do_pwritev fs/read_write.c:1036 [inline] __do_sys_pwritev fs/read_write.c:1083 [inline] __se_sys_pwritev fs/read_write.c:1078 [inline] __x64_sys_pwritev+0x235/0x310 fs/read_write.c:1078 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Found by Linux Verification Center (linuxtesting.org) with Syzkaller. CVE-2025-38328 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Use memcpy() for BIOS version The strlcat() with FORTIFY support is triggering a panic because it thinks the target buffer will overflow although the correct target buffer size is passed in. Anyway, instead of memset() with 0 followed by a strlcat(), just use memcpy() and ensure that the resulting buffer is NULL terminated. BIOSVersion is only used for the lpfc_printf_log() which expects a properly terminated string. CVE-2025-38332 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Prevent attempts to reclaim poisoned pages TL;DR: SGX page reclaim touches the page to copy its contents to secondary storage. SGX instructions do not gracefully handle machine checks. Despite this, the existing SGX code will try to reclaim pages that it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages. The longer story: Pages used by an enclave only get epc_page->poison set in arch_memory_failure() but they currently stay on sgx_active_page_list until sgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched. epc_page->poison is not checked in the reclaimer logic meaning that, if other conditions are met, an attempt will be made to reclaim an EPC page that was poisoned. This is bad because 1. we don't want that page to end up added to another enclave and 2. it is likely to cause one core to shut down and the kernel to panic. Specifically, reclaiming uses microcode operations including "EWB" which accesses the EPC page contents to encrypt and write them out to non-SGX memory. Those operations cannot handle MCEs in their accesses other than by putting the executing core into a special shutdown state (affecting both threads with HT.) The kernel will subsequently panic on the remaining cores seeing the core didn't enter MCE handler(s) in time. Call sgx_unmark_page_reclaimable() to remove the affected EPC page from sgx_active_page_list on memory error to stop it being considered for reclaiming. Testing epc_page->poison in sgx_reclaim_pages() would also work but I assume it's better to add code in the less likely paths. The affected EPC page is not added to &node->sgx_poison_page_list until later in sgx_encl_release()->sgx_free_epc_page() when it is EREMOVEd. Membership on other lists doesn't change to avoid changing any of the lists' semantics except for sgx_active_page_list. There's a "TBD" comment in arch_memory_failure() about pre-emptive actions, the goal here is not to address everything that it may imply. This also doesn't completely close the time window when a memory error notification will be fatal (for a not previously poisoned EPC page) -- the MCE can happen after sgx_reclaim_pages() has selected its candidates or even *inside* a microcode operation (actually easy to trigger due to the amount of time spent in them.) The spinlock in sgx_unmark_page_reclaimable() is safe because memory_failure() runs in process context and no spinlocks are held, explicitly noted in a mm/memory-failure.c comment. CVE-2025-38334 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT When enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in hard irq context, but the input_event() takes a spin_lock, which isn't allowed there as it is converted to a rt_spin_lock(). [ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0 ... [ 4054.290195] __might_resched+0x13c/0x1f4 [ 4054.290209] rt_spin_lock+0x54/0x11c [ 4054.290219] input_event+0x48/0x80 [ 4054.290230] gpio_keys_irq_timer+0x4c/0x78 [ 4054.290243] __hrtimer_run_queues+0x1a4/0x438 [ 4054.290257] hrtimer_interrupt+0xe4/0x240 [ 4054.290269] arch_timer_handler_phys+0x2c/0x44 [ 4054.290283] handle_percpu_devid_irq+0x8c/0x14c [ 4054.290297] handle_irq_desc+0x40/0x58 [ 4054.290307] generic_handle_domain_irq+0x1c/0x28 [ 4054.290316] gic_handle_irq+0x44/0xcc Considering the gpio_keys_irq_isr() can run in any context, e.g. it can be threaded, it seems there's no point in requesting the timer isr to run in hard irq context. Relax the hrtimer not to use the hard context. CVE-2025-38335 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330 The controller has a hardware bug that can hard hang the system when doing ATAPI DMAs without any trace of what happened. Depending on the device attached, it can also prevent the system from booting. In this case, the system hangs when reading the ATIP from optical media with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4, running at UDMA/33. The issue can be reproduced by running the same command with a cygwin build of cdrecord on WinXP, although it requires more attempts to cause it. The hang in that case is also resolved by forcing PIO. It doesn't appear that VIA has produced any drivers for that OS, thus no known workaround exists. HDDs attached to the controller do not suffer from any DMA issues. CVE-2025-38336 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate 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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio() Sometimes, when a file was read while it was being truncated by another NFS client, the kernel could deadlock because folio_unlock() was called twice, and the second call would XOR back the `PG_locked` flag. Most of the time (depending on the timing of the truncation), nobody notices the problem because folio_unlock() gets called three times, which flips `PG_locked` back off: 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio, nfs_return_empty_folio 2. vfs_read, nfs_read_folio, ... netfs_read_collection, netfs_unlock_abandoned_read_pages 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio, nfs_return_empty_folio The problem is that nfs_read_add_folio() is not supposed to unlock the folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is missing in nfs_return_empty_folio(). Rarely this leads to a warning in netfs_read_collection(): ------------[ cut here ]------------ R=0000031c: folio 10 is not locked WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00 [...] Workqueue: events_unbound netfs_read_collection_worker RIP: 0010:netfs_read_collection+0x7c0/0xf00 [...] Call Trace: <TASK> netfs_read_collection_worker+0x67/0x80 process_one_work+0x12e/0x2c0 worker_thread+0x295/0x3a0 Most of the time, however, processes just get stuck forever in folio_wait_bit_common(), waiting for `PG_locked` to disappear, which never happens because nobody is really holding the folio lock. CVE-2025-38338 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: software node: Correct a OOB check in software_node_get_reference_args() software_node_get_reference_args() wants to get @index-th element, so the property value requires at least '(index + 1) * sizeof(*ref)' bytes but that can not be guaranteed by current OOB check, and may cause OOB for malformed property. Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'. CVE-2025-38342 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: drop fragments with multicast or broadcast RA IEEE 802.11 fragmentation can only be applied to unicast frames. Therefore, drop fragments with multicast or broadcast RA. This patch addresses vulnerabilities such as CVE-2020-26145. CVE-2025-38343 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: ACPICA: fix acpi parse and parseext cache leaks ACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5 I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases. Boot log of ACPI cache leak is as follows: [ 0.352414] ACPI: Added _OSI(Module Device) [ 0.353182] ACPI: Added _OSI(Processor Device) [ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.353182] ACPI: Added _OSI(Processor Aggregator Device) [ 0.356028] ACPI: Unable to start the ACPI Interpreter [ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #10 [ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.361873] Call Trace: [ 0.362243] ? dump_stack+0x5c/0x81 [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27 [ 0.363296] ? acpi_os_delete_cache+0xa/0x10 [ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.364000] ? acpi_terminate+0xa/0x14 [ 0.364000] ? acpi_init+0x2af/0x34f [ 0.364000] ? __class_create+0x4c/0x80 [ 0.364000] ? video_setup+0x7f/0x7f [ 0.364000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.364000] ? do_one_initcall+0x4e/0x1a0 [ 0.364000] ? kernel_init_freeable+0x189/0x20a [ 0.364000] ? rest_init+0xc0/0xc0 [ 0.364000] ? kernel_init+0xa/0x100 [ 0.364000] ? ret_from_fork+0x25/0x30 I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size. I finally found “Acpi-Parse” cache and “Acpi-parse_ext” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function. Real ACPI cache leak point is as follows: [ 0.360101] ACPI: Added _OSI(Module Device) [ 0.360101] ACPI: Added _OSI(Processor Device) [ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.361043] ACPI: Added _OSI(Processor Aggregator Device) [ 0.364016] ACPI: Unable to start the ACPI Interpreter [ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.372000] Call Trace: [ 0.372000] ? dump_stack+0x5c/0x81 [ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? acpi_os_delete_cache+0xa/0x10 [ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b [ 0.372000] ? acpi_terminate+0xa/0x14 [ 0.372000] ? acpi_init+0x2af/0x34f [ 0.372000] ? __class_create+0x4c/0x80 [ 0.372000] ? video_setup+0x7f/0x7f [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? do_one_initcall+0x4e/0x1a0 [ 0.372000] ? kernel_init_freeable+0x189/0x20a [ 0.372000] ? rest_init+0xc0/0xc0 [ 0.372000] ? kernel_init+0xa/0x100 [ 0.372000] ? ret_from_fork+0x25/0x30 [ 0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.392000] Call Trace: [ 0.392000] ? dump_stack+0x5c/0x81 [ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? acpi_os_delete_cache+0xa/0x10 [ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.392000] ? acpi_terminate+0xa/0x14 [ 0.392000] ? acpi_init+0x2af/0x3 ---truncated--- CVE-2025-38344 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: ACPICA: fix acpi operand cache leak in dswstate.c ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. CVE-2025-38345 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback() Robert Morris reported: |If a malicious USB device pretends to be an Intersil p54 wifi |interface and generates an eeprom_readback message with a large |eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the |message beyond the end of priv->eeprom. | |static void p54_rx_eeprom_readback(struct p54_common *priv, | struct sk_buff *skb) |{ | struct p54_hdr *hdr = (struct p54_hdr *) skb->data; | struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr->data; | | if (priv->fw_var >= 0x509) { | memcpy(priv->eeprom, eeprom->v2.data, | le16_to_cpu(eeprom->v2.len)); | } else { | memcpy(priv->eeprom, eeprom->v1.data, | le16_to_cpu(eeprom->v1.len)); | } | [...] The eeprom->v{1,2}.len is set by the driver in p54_download_eeprom(). The device is supposed to provide the same length back to the driver. But yes, it's possible (like shown in the report) to alter the value to something that causes a crash/panic due to overrun. This patch addresses the issue by adding the size to the common device context, so p54_rx_eeprom_readback no longer relies on possibly tampered values... That said, it also checks if the "firmware" altered the value and no longer copies them. The one, small saving grace is: Before the driver tries to read the eeprom, it needs to upload >a< firmware. the vendor firmware has a proprietary license and as a reason, it is not present on most distributions by default. CVE-2025-38348 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: eventpoll: don't decrement ep refcount while still holding the ep mutex Jann Horn points out that epoll is decrementing the ep refcount and then doing a mutex_unlock(&ep->mtx); afterwards. That's very wrong, because it can lead to a use-after-free. That pattern is actually fine for the very last reference, because the code in question will delay the actual call to "ep_free(ep)" until after it has unlocked the mutex. But it's wrong for the much subtler "next to last" case when somebody *else* may also be dropping their reference and free the ep while we're still using the mutex. Note that this is true even if that other user is also using the same ep mutex: mutexes, unlike spinlocks, can not be used for object ownership, even if they guarantee mutual exclusion. A mutex "unlock" operation is not atomic, and as one user is still accessing the mutex as part of unlocking it, another user can come in and get the now released mutex and free the data structure while the first user is still cleaning up. See our mutex documentation in Documentation/locking/mutex-design.rst, in particular the section [1] about semantics: "mutex_unlock() may access the mutex structure even after it has internally released the lock already - so it's not safe for another context to acquire the mutex and assume that the mutex_unlock() context is not using the structure anymore" So if we drop our ep ref before the mutex unlock, but we weren't the last one, we may then unlock the mutex, another user comes in, drops _their_ reference and releases the 'ep' as it now has no users - all while the mutex_unlock() is still accessing it. Fix this by simply moving the ep refcount dropping to outside the mutex: the refcount itself is atomic, and doesn't need mutex protection (that's the whole _point_ of refcounts: unlike mutexes, they are inherently about object lifetimes). CVE-2025-38349 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: drm/msm/gpu: Fix crash when throttling GPU immediately during boot There is a small chance that the GPU is already hot during boot. In that case, the call to of_devfreq_cooling_register() will immediately try to apply devfreq cooling, as seen in the following crash: Unable to handle kernel paging request at virtual address 0000000000014110 pc : a6xx_gpu_busy+0x1c/0x58 [msm] lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm] Call trace: a6xx_gpu_busy+0x1c/0x58 [msm] (P) devfreq_simple_ondemand_func+0x3c/0x150 devfreq_update_target+0x44/0xd8 qos_max_notifier_call+0x30/0x84 blocking_notifier_call_chain+0x6c/0xa0 pm_qos_update_target+0xd0/0x110 freq_qos_apply+0x3c/0x74 apply_constraint+0x88/0x148 __dev_pm_qos_update_request+0x7c/0xcc dev_pm_qos_update_request+0x38/0x5c devfreq_cooling_set_cur_state+0x98/0xf0 __thermal_cdev_update+0x64/0xb4 thermal_cdev_update+0x4c/0x58 step_wise_manage+0x1f0/0x318 __thermal_zone_device_update+0x278/0x424 __thermal_cooling_device_register+0x2bc/0x308 thermal_of_cooling_device_register+0x10/0x1c of_devfreq_cooling_register_power+0x240/0x2bc of_devfreq_cooling_register+0x14/0x20 msm_devfreq_init+0xc4/0x1a0 [msm] msm_gpu_init+0x304/0x574 [msm] adreno_gpu_init+0x1c4/0x2e0 [msm] a6xx_gpu_init+0x5c8/0x9c8 [msm] adreno_bind+0x2a8/0x33c [msm] ... At this point we haven't initialized the GMU at all yet, so we cannot read the GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before in commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in 6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), but unlike msm_devfreq_suspend(), it doesn't set the df->suspended flag accordingly. This means the df->suspended flag does not match the actual devfreq state after initialization and msm_devfreq_get_dev_status() will end up accessing GMU registers, causing the crash. Fix this by setting df->suspended correctly during initialization. Patchwork: https://patchwork.freedesktop.org/patch/650772/ CVE-2025-38354 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null pointer check for get_first_active_display() The function mod_hdcp_hdcp1_enable_encryption() calls the function get_first_active_display(), but does not check its return value. The return value is a null pointer if the display list is empty. This will lead to a null pointer dereference in mod_hdcp_hdcp2_enable_encryption(). Add a null pointer check for get_first_active_display() and return MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null. CVE-2025-38362 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix a possible null pointer dereference In tegra_crtc_reset(), new memory is allocated with kzalloc(), but no check is performed. Before calling __drm_atomic_helper_crtc_reset, state should be checked to prevent possible null pointer dereference. CVE-2025-38363 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate() Temporarily clear the preallocation flag when explicitly requesting allocations. Pre-existing allocations are already counted against the request through mas_node_count_gfp(), but the allocations will not happen if the MA_STATE_PREALLOC flag is set. This flag is meant to avoid re-allocating in bulk allocation mode, and to detect issues with preallocation calculations. The MA_STATE_PREALLOC flag should also always be set on zero allocations so that detection of underflow allocations will print a WARN_ON() during consumption. User visible effect of this flaw is a WARN_ON() followed by a null pointer dereference when subsequent requests for larger number of nodes is ignored, such as the vma merge retry in mmap_region() caused by drivers altering the vma flags (which happens in v6.6, at least) CVE-2025-38364 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a race between renames and directory logging We have a race between a rename and directory inode logging that if it happens and we crash/power fail before the rename completes, the next time the filesystem is mounted, the log replay code will end up deleting the file that was being renamed. This is best explained following a step by step analysis of an interleaving of steps that lead into this situation. Consider the initial conditions: 1) We are at transaction N; 2) We have directories A and B created in a past transaction (< N); 3) We have inode X corresponding to a file that has 2 hardlinks, one in directory A and the other in directory B, so we'll name them as "A/foo_link1" and "B/foo_link2". Both hard links were persisted in a past transaction (< N); 4) We have inode Y corresponding to a file that as a single hard link and is located in directory A, we'll name it as "A/bar". This file was also persisted in a past transaction (< N). The steps leading to a file loss are the following and for all of them we are under transaction N: 1) Link "A/foo_link1" is removed, so inode's X last_unlink_trans field is updated to N, through btrfs_unlink() -> btrfs_record_unlink_dir(); 2) Task A starts a rename for inode Y, with the goal of renaming from "A/bar" to "A/baz", so we enter btrfs_rename(); 3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling btrfs_insert_inode_ref(); 4) Because the rename happens in the same directory, we don't set the last_unlink_trans field of directoty A's inode to the current transaction id, that is, we don't cal btrfs_record_unlink_dir(); 5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode() (actually the dir index item is added as a delayed item, but the effect is the same); 6) Now before task A adds the new entry "A/baz" to directory A by calling btrfs_add_link(), another task, task B is logging inode X; 7) Task B starts a fsync of inode X and after logging inode X, at btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since inode X has a last_unlink_trans value of N, set at in step 1; 8) At btrfs_log_all_parents() we search for all parent directories of inode X using the commit root, so we find directories A and B and log them. Bu when logging direct A, we don't have a dir index item for inode Y anymore, neither the old name "A/bar" nor for the new name "A/baz" since the rename has deleted the old name but has not yet inserted the new name - task A hasn't called yet btrfs_add_link() to do that. Note that logging directory A doesn't fallback to a transaction commit because its last_unlink_trans has a lower value than the current transaction's id (see step 4); 9) Task B finishes logging directories A and B and gets back to btrfs_sync_file() where it calls btrfs_sync_log() to persist the log tree; 10) Task B successfully persisted the log tree, btrfs_sync_log() completed with success, and a power failure happened. We have a log tree without any directory entry for inode Y, so the log replay code deletes the entry for inode Y, name "A/bar", from the subvolume tree since it doesn't exist in the log tree and the log tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY item that covers the index range for the dentry that corresponds to "A/bar"). Since there's no other hard link for inode Y and the log replay code deletes the name "A/bar", the file is lost. The issue wouldn't happen if task B synced the log only after task A called btrfs_log_new_name(), which would update the log with the new name for inode Y ("A/bar"). Fix this by pinning the log root during renames before removing the old directory entry, and unpinning af ---truncated--- CVE-2025-38365 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before using Running IDXD workloads in a container with the /dev directory mounted can trigger a call trace or even a kernel panic when the parent process of the container is terminated. This issue occurs because, under certain configurations, Docker does not properly propagate the mount replica back to the original mount point. In this case, when the user driver detaches, the WQ is destroyed but it still calls destroy_workqueue() attempting to completes all pending work. It's necessary to check wq->wq and skip the drain if it no longer exists. CVE-2025-38369 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Disable interrupts before resetting the GPU Currently, an interrupt can be triggered during a GPU reset, which can lead to GPU hangs and NULL pointer dereference in an interrupt context as shown in the following trace: [ 314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0 [ 314.043822] Mem abort info: [ 314.046606] ESR = 0x0000000096000005 [ 314.050347] EC = 0x25: DABT (current EL), IL = 32 bits [ 314.055651] SET = 0, FnV = 0 [ 314.058695] EA = 0, S1PTW = 0 [ 314.061826] FSC = 0x05: level 1 translation fault [ 314.066694] Data abort info: [ 314.069564] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 314.075039] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 314.080080] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 314.085382] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000102728000 [ 314.091814] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 314.100511] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 314.106770] Modules linked in: v3d i2c_brcmstb vc4 snd_soc_hdmi_codec gpu_sched drm_shmem_helper drm_display_helper cec drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 314.129654] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1 [ 314.139388] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 314.145211] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 314.152165] pc : v3d_irq+0xec/0x2e0 [v3d] [ 314.156187] lr : v3d_irq+0xe0/0x2e0 [v3d] [ 314.160198] sp : ffffffc080003ea0 [ 314.163502] x29: ffffffc080003ea0 x28: ffffffec1f184980 x27: 021202b000000000 [ 314.170633] x26: ffffffec1f17f630 x25: ffffff8101372000 x24: ffffffec1f17d9f0 [ 314.177764] x23: 000000000000002a x22: 000000000000002a x21: ffffff8103252000 [ 314.184895] x20: 0000000000000001 x19: 00000000deadbeef x18: 0000000000000000 [ 314.192026] x17: ffffff94e51d2000 x16: ffffffec1dac3cb0 x15: c306000000000000 [ 314.199156] x14: 0000000000000000 x13: b2fc982e03cc5168 x12: 0000000000000001 [ 314.206286] x11: ffffff8103f8bcc0 x10: ffffffec1f196868 x9 : ffffffec1dac3874 [ 314.213416] x8 : 0000000000000000 x7 : 0000000000042a3a x6 : ffffff810017a180 [ 314.220547] x5 : ffffffec1ebad400 x4 : ffffffec1ebad320 x3 : 00000000000bebeb [ 314.227677] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 314.234807] Call trace: [ 314.237243] v3d_irq+0xec/0x2e0 [v3d] [ 314.240906] __handle_irq_event_percpu+0x58/0x218 [ 314.245609] handle_irq_event+0x54/0xb8 [ 314.249439] handle_fasteoi_irq+0xac/0x240 [ 314.253527] handle_irq_desc+0x48/0x68 [ 314.257269] generic_handle_domain_irq+0x24/0x38 [ 314.261879] gic_handle_irq+0x48/0xd8 [ 314.265533] call_on_irq_stack+0x24/0x58 [ 314.269448] do_interrupt_handler+0x88/0x98 [ 314.273624] el1_interrupt+0x34/0x68 [ 314.277193] el1h_64_irq_handler+0x18/0x28 [ 314.281281] el1h_64_irq+0x64/0x68 [ 314.284673] default_idle_call+0x3c/0x168 [ 314.288675] do_idle+0x1fc/0x230 [ 314.291895] cpu_startup_entry+0x3c/0x50 [ 314.295810] rest_init+0xe4/0xf0 [ 314.299030] start_kernel+0x5e8/0x790 [ 314.302684] __primary_switched+0x80/0x90 [ 314.306691] Code: 940029eb 360ffc13 f9442ea0 52800001 (f9406017) [ 314.312775] ---[ end trace 0000000000000000 ]--- [ 314.317384] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 314.324249] SMP: stopping secondary CPUs [ 314.328167] Kernel Offset: 0x2b9da00000 from 0xffffffc080000000 [ 314.334076] PHYS_OFFSET: 0x0 [ 314.336946] CPU features: 0x08,00002013,c0200000,0200421b [ 314.342337] Memory Limit: none [ 314.345382] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- Before resetting the G ---truncated--- CVE-2025-38371 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix potential deadlock in MR deregistration The issue arises when kzalloc() is invoked while holding umem_mutex or any other lock acquired under umem_mutex. This is problematic because kzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke mmu_notifier_invalidate_range_start(). This function can lead to mlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again, resulting in a deadlock. The problematic flow: CPU0 | CPU1 ---------------------------------------|------------------------------------------------ mlx5_ib_dereg_mr() | -> revoke_mr() | -> mutex_lock(&umem_odp->umem_mutex) | | mlx5_mkey_cache_init() | -> mutex_lock(&dev->cache.rb_lock) | -> mlx5r_cache_create_ent_locked() | -> kzalloc(GFP_KERNEL) | -> fs_reclaim() | -> mmu_notifier_invalidate_range_start() | -> mlx5_ib_invalidate_range() | -> mutex_lock(&umem_odp->umem_mutex) -> cache_ent_find_and_store() | -> mutex_lock(&dev->cache.rb_lock) | Additionally, when kzalloc() is called from within cache_ent_find_and_store(), we encounter the same deadlock due to re-acquisition of umem_mutex. Solve by releasing umem_mutex in dereg_mr() after umr_revoke_mr() and before acquiring rb_lock. This ensures that we don't hold umem_mutex while performing memory allocations that could trigger the reclaim path. This change prevents the deadlock by ensuring proper lock ordering and avoiding holding locks during memory allocation operations that could trigger the reclaim path. The following lockdep warning demonstrates the deadlock: python3/20557 is trying to acquire lock: ffff888387542128 (&umem_odp->umem_mutex){+.+.}-{4:4}, at: mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib] but task is already holding lock: ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: unmap_vmas+0x7b/0x1a0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x60/0xd0 mem_cgroup_css_alloc+0x6f/0x9b0 cgroup_init_subsys+0xa4/0x240 cgroup_init+0x1c8/0x510 start_kernel+0x747/0x760 x86_64_start_reservations+0x25/0x30 x86_64_start_kernel+0x73/0x80 common_startup_64+0x129/0x138 -> #2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x91/0xd0 __kmalloc_cache_noprof+0x4d/0x4c0 mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib] mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib] mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib] __mlx5_ib_add+0x4b/0x190 [mlx5_ib] mlx5r_probe+0xd9/0x320 [mlx5_ib] auxiliary_bus_probe+0x42/0x70 really_probe+0xdb/0x360 __driver_probe_device+0x8f/0x130 driver_probe_device+0x1f/0xb0 __driver_attach+0xd4/0x1f0 bus_for_each_dev+0x79/0xd0 bus_add_driver+0xf0/0x200 driver_register+0x6e/0xc0 __auxiliary_driver_register+0x6a/0xc0 do_one_initcall+0x5e/0x390 do_init_module+0x88/0x240 init_module_from_file+0x85/0xc0 idempotent_init_module+0x104/0x300 __x64_sys_finit_module+0x68/0xc0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #1 (&dev->cache.rb_lock){+.+.}-{4:4}: __mutex_lock+0x98/0xf10 __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib] mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib] ib_dereg_mr_user+0x85/0x1f0 [ib_core] ---truncated--- CVE-2025-38373 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate 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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: usb: chipidea: udc: disconnect/reconnect from host when do suspend/resume Shawn and John reported a hang issue during system suspend as below: - USB gadget is enabled as Ethernet - There is data transfer over USB Ethernet (scp a big file between host and device) - Device is going in/out suspend (echo mem > /sys/power/state) The root cause is the USB device controller is suspended but the USB bus is still active which caused the USB host continues to transfer data with device and the device continues to queue USB requests (in this case, a delayed TCP ACK packet trigger the issue) after controller is suspended, however the USB controller clock is already gated off. Then if udc driver access registers after that point, the system will hang. The correct way to avoid such issue is to disconnect device from host when the USB bus is not at suspend state. Then the host will receive disconnect event and stop data transfer in time. To continue make USB gadget device work after system resume, this will reconnect device automatically. To make usb wakeup work if USB bus is already at suspend state, this will keep connection for it only when USB device controller has enabled wakeup capability. CVE-2025-38376 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: rose: fix dangling neighbour pointers in rose_rt_device_down() There are two bugs in rose_rt_device_down() that can cause use-after-free: 1. The loop bound `t->count` is modified within the loop, which can cause the loop to terminate early and miss some entries. 2. When removing an entry from the neighbour array, the subsequent entries are moved up to fill the gap, but the loop index `i` is still incremented, causing the next entry to be skipped. For example, if a node has three neighbours (A, A, B) with count=3 and A is being removed, the second A is not checked. i=0: (A, A, B) -> (A, B) with count=2 ^ checked i=1: (A, B) -> (A, B) with count=2 ^ checked (B, not A!) i=2: (doesn't occur because i < count is false) This leaves the second A in the array with count=2, but the rose_neigh structure has been freed. Code that accesses these entries assumes that the first `count` entries are valid pointers, causing a use-after-free when it accesses the dangling pointer. Fix both issues by iterating over the array in reverse order with a fixed loop bound. This ensures that all entries are examined and that the removal of an entry doesn't affect subsequent iterations. CVE-2025-38377 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. CVE-2025-38380 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: btrfs: fix iteration of extrefs during log replay At __inode_add_ref() when processing extrefs, if we jump into the next label we have an undefined value of victim_name.len, since we haven't initialized it before we did the goto. This results in an invalid memory access in the next iteration of the loop since victim_name.len was not initialized to the length of the name of the current extref. Fix this by initializing victim_name.len with the current extref's name length. CVE-2025-38382 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: mtd: spinand: fix memory leak of ECC engine conf Memory allocated for the ECC engine conf is not released during spinand cleanup. Below kmemleak trace is seen for this memory leak: unreferenced object 0xffffff80064f00e0 (size 8): comm "swapper/0", pid 1, jiffies 4294937458 hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace (crc 0): kmemleak_alloc+0x30/0x40 __kmalloc_cache_noprof+0x208/0x3c0 spinand_ondie_ecc_init_ctx+0x114/0x200 nand_ecc_init_ctx+0x70/0xa8 nanddev_ecc_engine_init+0xec/0x27c spinand_probe+0xa2c/0x1620 spi_mem_probe+0x130/0x21c spi_probe+0xf0/0x170 really_probe+0x17c/0x6e8 __driver_probe_device+0x17c/0x21c driver_probe_device+0x58/0x180 __device_attach_driver+0x15c/0x1f8 bus_for_each_drv+0xec/0x150 __device_attach+0x188/0x24c device_initial_probe+0x10/0x20 bus_probe_device+0x11c/0x160 Fix the leak by calling nanddev_ecc_engine_cleanup() inside spinand_cleanup(). CVE-2025-38384 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 low In the Linux kernel, the following vulnerability has been resolved: net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect Remove redundant netif_napi_del() call from disconnect path. A WARN may be triggered in __netif_napi_del_locked() during USB device disconnect: WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350 This happens because netif_napi_del() is called in the disconnect path while NAPI is still enabled. However, it is not necessary to call netif_napi_del() explicitly, since unregister_netdev() will handle NAPI teardown automatically and safely. Removing the redundant call avoids triggering the warning. Full trace: lan78xx 1-1:1.0 enu1: Failed to read register index 0x000000c4. ret = -ENODEV lan78xx 1-1:1.0 enu1: Failed to set MAC down with error -ENODEV lan78xx 1-1:1.0 enu1: Link is Down lan78xx 1-1:1.0 enu1: Failed to read register index 0x00000120. ret = -ENODEV ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350 Modules linked in: flexcan can_dev fuse CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.0-rc2-00624-ge926949dab03 #9 PREEMPT Hardware name: SKOV IMX8MP CPU revC - bd500 (DT) Workqueue: usb_hub_wq hub_event pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __netif_napi_del_locked+0x2b4/0x350 lr : __netif_napi_del_locked+0x7c/0x350 sp : ffffffc085b673c0 x29: ffffffc085b673c0 x28: ffffff800b7f2000 x27: ffffff800b7f20d8 x26: ffffff80110bcf58 x25: ffffff80110bd978 x24: 1ffffff0022179eb x23: ffffff80110bc000 x22: ffffff800b7f5000 x21: ffffff80110bc000 x20: ffffff80110bcf38 x19: ffffff80110bcf28 x18: dfffffc000000000 x17: ffffffc081578940 x16: ffffffc08284cee0 x15: 0000000000000028 x14: 0000000000000006 x13: 0000000000040000 x12: ffffffb0022179e8 x11: 1ffffff0022179e7 x10: ffffffb0022179e7 x9 : dfffffc000000000 x8 : 0000004ffdde8619 x7 : ffffff80110bcf3f x6 : 0000000000000001 x5 : ffffff80110bcf38 x4 : ffffff80110bcf38 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 1ffffff0022179e7 x0 : 0000000000000000 Call trace: __netif_napi_del_locked+0x2b4/0x350 (P) lan78xx_disconnect+0xf4/0x360 usb_unbind_interface+0x158/0x718 device_remove+0x100/0x150 device_release_driver_internal+0x308/0x478 device_release_driver+0x1c/0x30 bus_remove_device+0x1a8/0x368 device_del+0x2e0/0x7b0 usb_disable_device+0x244/0x540 usb_disconnect+0x220/0x758 hub_event+0x105c/0x35e0 process_one_work+0x760/0x17b0 worker_thread+0x768/0xce8 kthread+0x3bc/0x690 ret_from_fork+0x10/0x20 irq event stamp: 211604 hardirqs last enabled at (211603): [<ffffffc0828cc9ec>] _raw_spin_unlock_irqrestore+0x84/0x98 hardirqs last disabled at (211604): [<ffffffc0828a9a84>] el1_dbg+0x24/0x80 softirqs last enabled at (211296): [<ffffffc080095f10>] handle_softirqs+0x820/0xbc8 softirqs last disabled at (210993): [<ffffffc080010288>] __do_softirq+0x18/0x20 ---[ end trace 0000000000000000 ]--- lan78xx 1-1:1.0 enu1: failed to kill vid 0081/0 CVE-2025-38385 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 low 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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Initialize obj_event->obj_sub_list before xa_insert The obj_event may be loaded immediately after inserted, then if the list_head is not initialized then we may get a poisonous pointer. This fixes the crash below: mlx5_core 0000:03:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(2048) RxCqeCmprss(0 enhanced) mlx5_core.sf mlx5_core.sf.4: firmware version: 32.38.3056 mlx5_core 0000:03:00.0 en3f0pf0sf2002: renamed from eth0 mlx5_core.sf mlx5_core.sf.4: Rate limit: 127 rates are supported, range: 0Mbps to 195312Mbps IPv6: ADDRCONF(NETDEV_CHANGE): en3f0pf0sf2002: link becomes ready Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000007760fb000 [0000000000000060] pgd=000000076f6d7003, p4d=000000076f6d7003, pud=0000000777841003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] SMP Modules linked in: ipmb_host(OE) act_mirred(E) cls_flower(E) sch_ingress(E) mptcp_diag(E) udp_diag(E) raw_diag(E) unix_diag(E) tcp_diag(E) inet_diag(E) binfmt_misc(E) bonding(OE) rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) isofs(E) cdrom(E) mst_pciconf(OE) ib_umad(OE) mlx5_ib(OE) ipmb_dev_int(OE) mlx5_core(OE) kpatch_15237886(OEK) mlxdevm(OE) auxiliary(OE) ib_uverbs(OE) ib_core(OE) psample(E) mlxfw(OE) tls(E) sunrpc(E) vfat(E) fat(E) crct10dif_ce(E) ghash_ce(E) sha1_ce(E) sbsa_gwdt(E) virtio_console(E) ext4(E) mbcache(E) jbd2(E) xfs(E) libcrc32c(E) mmc_block(E) virtio_net(E) net_failover(E) failover(E) sha2_ce(E) sha256_arm64(E) nvme(OE) nvme_core(OE) gpio_mlxbf3(OE) mlx_compat(OE) mlxbf_pmc(OE) i2c_mlxbf(OE) sdhci_of_dwcmshc(OE) pinctrl_mlxbf3(OE) mlxbf_pka(OE) gpio_generic(E) i2c_core(E) mmc_core(E) mlxbf_gige(OE) vitesse(E) pwr_mlxbf(OE) mlxbf_tmfifo(OE) micrel(E) mlxbf_bootctl(OE) virtio_ring(E) virtio(E) ipmi_devintf(E) ipmi_msghandler(E) [last unloaded: mst_pci] CPU: 11 PID: 20913 Comm: rte-worker-11 Kdump: loaded Tainted: G OE K 5.10.134-13.1.an8.aarch64 #1 Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.2.2.12968 Oct 26 2023 pstate: a0400089 (NzCv daIf +PAN -UAO -TCO BTYPE=--) pc : dispatch_event_fd+0x68/0x300 [mlx5_ib] lr : devx_event_notifier+0xcc/0x228 [mlx5_ib] sp : ffff80001005bcf0 x29: ffff80001005bcf0 x28: 0000000000000001 x27: ffff244e0740a1d8 x26: ffff244e0740a1d0 x25: ffffda56beff5ae0 x24: ffffda56bf911618 x23: ffff244e0596a480 x22: ffff244e0596a480 x21: ffff244d8312ad90 x20: ffff244e0596a480 x19: fffffffffffffff0 x18: 0000000000000000 x17: 0000000000000000 x16: ffffda56be66d620 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000040 x10: ffffda56bfcafb50 x9 : ffffda5655c25f2c x8 : 0000000000000010 x7 : 0000000000000000 x6 : ffff24545a2e24b8 x5 : 0000000000000003 x4 : ffff80001005bd28 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff244e0596a480 x0 : ffff244d8312ad90 Call trace: dispatch_event_fd+0x68/0x300 [mlx5_ib] devx_event_notifier+0xcc/0x228 [mlx5_ib] atomic_notifier_call_chain+0x58/0x80 mlx5_eq_async_int+0x148/0x2b0 [mlx5_core] atomic_notifier_call_chain+0x58/0x80 irq_int_handler+0x20/0x30 [mlx5_core] __handle_irq_event_percpu+0x60/0x220 handle_irq_event_percpu+0x3c/0x90 handle_irq_event+0x58/0x158 handle_fasteoi_irq+0xfc/0x188 generic_handle_irq+0x34/0x48 ... CVE-2025-38387 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix timeline left held on VMA alloc error The following error has been reported sporadically by CI when a test unbinds the i915 driver on a ring submission platform: <4> [239.330153] ------------[ cut here ]------------ <4> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count) <4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330942] Call Trace: <4> [239.330944] <TASK> <4> [239.330949] i915_driver_late_release+0x2b/0xa0 [i915] <4> [239.331202] i915_driver_release+0x86/0xa0 [i915] <4> [239.331482] devm_drm_dev_init_release+0x61/0x90 <4> [239.331494] devm_action_release+0x15/0x30 <4> [239.331504] release_nodes+0x3d/0x120 <4> [239.331517] devres_release_all+0x96/0xd0 <4> [239.331533] device_unbind_cleanup+0x12/0x80 <4> [239.331543] device_release_driver_internal+0x23a/0x280 <4> [239.331550] ? bus_find_device+0xa5/0xe0 <4> [239.331563] device_driver_detach+0x14/0x20 ... <4> [357.719679] ---[ end trace 0000000000000000 ]--- If the test also unloads the i915 module then that's followed with: <3> [357.787478] ============================================================================= <3> [357.788006] BUG i915_vma (Tainted: G U W N ): Objects remaining on __kmem_cache_shutdown() <3> [357.788031] ----------------------------------------------------------------------------- <3> [357.788204] Object 0xffff888109e7f480 @offset=29824 <3> [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244 <4> [357.788994] i915_vma_instance+0xee/0xc10 [i915] <4> [357.789290] init_status_page+0x7b/0x420 [i915] <4> [357.789532] intel_engines_init+0x1d8/0x980 [i915] <4> [357.789772] intel_gt_init+0x175/0x450 [i915] <4> [357.790014] i915_gem_init+0x113/0x340 [i915] <4> [357.790281] i915_driver_probe+0x847/0xed0 [i915] <4> [357.790504] i915_pci_probe+0xe6/0x220 [i915] ... Closer analysis of CI results history has revealed a dependency of the error on a few IGT tests, namely: - igt@api_intel_allocator@fork-simple-stress-signal, - igt@api_intel_allocator@two-level-inception-interruptible, - igt@gem_linear_blits@interruptible, - igt@prime_mmap_coherency@ioctl-errors, which invisibly trigger the issue, then exhibited with first driver unbind attempt. All of the above tests perform actions which are actively interrupted with signals. Further debugging has allowed to narrow that scope down to DRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring submission, in particular. If successful then that function, or its execlists or GuC submission equivalent, is supposed to be called only once per GEM context engine, followed by raise of a flag that prevents the function from being called again. The function is expected to unwind its internal errors itself, so it may be safely called once more after it returns an error. In case of ring submission, the function first gets a reference to the engine's legacy timeline and then allocates a VMA. If the VMA allocation fails, e.g. when i915_vma_instance() called from inside is interrupted with a signal, then ring_context_alloc() fails, leaving the timeline held referenced. On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the timeline is got, and only that last one is put on successful completion. As a consequence, the legacy timeline, with its underlying engine status page's VMA object, is still held and not released on driver unbind. Get the legacy timeline only after successful allocation of the context engine's VMA. v2: Add a note on other submission methods (Krzysztof Karas): Both execlists and GuC submission use lrc_alloc() which seems free from a similar issue. (cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f) CVE-2025-38389 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: idpf: convert control queue mutex to a spinlock With VIRTCHNL2_CAP_MACFILTER enabled, the following warning is generated on module load: [ 324.701677] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578 [ 324.701684] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1582, name: NetworkManager [ 324.701689] preempt_count: 201, expected: 0 [ 324.701693] RCU nest depth: 0, expected: 0 [ 324.701697] 2 locks held by NetworkManager/1582: [ 324.701702] #0: ffffffff9f7be770 (rtnl_mutex){....}-{3:3}, at: rtnl_newlink+0x791/0x21e0 [ 324.701730] #1: ff1100216c380368 (_xmit_ETHER){....}-{2:2}, at: __dev_open+0x3f0/0x870 [ 324.701749] Preemption disabled at: [ 324.701752] [<ffffffff9cd23b9d>] __dev_open+0x3dd/0x870 [ 324.701765] CPU: 30 UID: 0 PID: 1582 Comm: NetworkManager Not tainted 6.15.0-rc5+ #2 PREEMPT(voluntary) [ 324.701771] Hardware name: Intel Corporation M50FCP2SBSTD/M50FCP2SBSTD, BIOS SE5C741.86B.01.01.0001.2211140926 11/14/2022 [ 324.701774] Call Trace: [ 324.701777] <TASK> [ 324.701779] dump_stack_lvl+0x5d/0x80 [ 324.701788] ? __dev_open+0x3dd/0x870 [ 324.701793] __might_resched.cold+0x1ef/0x23d <..> [ 324.701818] __mutex_lock+0x113/0x1b80 <..> [ 324.701917] idpf_ctlq_clean_sq+0xad/0x4b0 [idpf] [ 324.701935] ? kasan_save_track+0x14/0x30 [ 324.701941] idpf_mb_clean+0x143/0x380 [idpf] <..> [ 324.701991] idpf_send_mb_msg+0x111/0x720 [idpf] [ 324.702009] idpf_vc_xn_exec+0x4cc/0x990 [idpf] [ 324.702021] ? rcu_is_watching+0x12/0xc0 [ 324.702035] idpf_add_del_mac_filters+0x3ed/0xb50 [idpf] <..> [ 324.702122] __hw_addr_sync_dev+0x1cf/0x300 [ 324.702126] ? find_held_lock+0x32/0x90 [ 324.702134] idpf_set_rx_mode+0x317/0x390 [idpf] [ 324.702152] __dev_open+0x3f8/0x870 [ 324.702159] ? __pfx___dev_open+0x10/0x10 [ 324.702174] __dev_change_flags+0x443/0x650 <..> [ 324.702208] netif_change_flags+0x80/0x160 [ 324.702218] do_setlink.isra.0+0x16a0/0x3960 <..> [ 324.702349] rtnl_newlink+0x12fd/0x21e0 The sequence is as follows: rtnl_newlink()-> __dev_change_flags()-> __dev_open()-> dev_set_rx_mode() - > # disables BH and grabs "dev->addr_list_lock" idpf_set_rx_mode() -> # proceed only if VIRTCHNL2_CAP_MACFILTER is ON __dev_uc_sync() -> idpf_add_mac_filter -> idpf_add_del_mac_filters -> idpf_send_mb_msg() -> idpf_mb_clean() -> idpf_ctlq_clean_sq() # mutex_lock(cq_lock) Fix by converting cq_lock to a spinlock. All operations under the new lock are safe except freeing the DMA memory, which may use vunmap(). Fix by requesting a contiguous physical memory for the DMA mapping. CVE-2025-38392 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN We found a few different systems hung up in writeback waiting on the same page lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in pnfs_update_layout(), however the pnfs_layout_hdr's plh_outstanding count was zero. It seems most likely that this is another race between the waiter and waker similar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task"). Fix it up by applying the advised barrier. CVE-2025-38393 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods drvdata::gpiods is supposed to hold an array of 'gpio_desc' pointers. But the memory is allocated for only one pointer. This will lead to out-of-bounds access later in the code if 'config::ngpios' is > 1. So fix the code to allocate enough memory to hold 'config::ngpios' of GPIO descriptors. While at it, also move the check for memory allocation failure to be below the allocation to make it more readable. CVE-2025-38395 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: fs: export anon_inode_make_secure_inode() and fix secretmem LSM bypass Export anon_inode_make_secure_inode() to allow KVM guest_memfd to create anonymous inodes with proper security context. This replaces the current pattern of calling alloc_anon_inode() followed by inode_init_security_anon() for creating security context manually. This change also fixes a security regression in secretmem where the S_PRIVATE flag was not cleared after alloc_anon_inode(), causing LSM/SELinux checks to be bypassed for secretmem file descriptors. As guest_memfd currently resides in the KVM module, we need to export this symbol for use outside the core kernel. In the future, guest_memfd might be moved to core-mm, at which point the symbols no longer would have to be exported. When/if that happens is still unclear. CVE-2025-38396 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port() The function core_scsi3_decode_spec_i_port(), in its error code path, unconditionally calls core_scsi3_lunacl_undepend_item() passing the dest_se_deve pointer, which may be NULL. This can lead to a NULL pointer dereference if dest_se_deve remains unset. SPC-3 PR SPEC_I_PT: Unable to locate dest_tpg Unable to handle kernel paging request at virtual address dfff800000000012 Call trace: core_scsi3_lunacl_undepend_item+0x2c/0xf0 [target_core_mod] (P) core_scsi3_decode_spec_i_port+0x120c/0x1c30 [target_core_mod] core_scsi3_emulate_pro_register+0x6b8/0xcd8 [target_core_mod] target_scsi3_emulate_pr_out+0x56c/0x840 [target_core_mod] Fix this by adding a NULL check before calling core_scsi3_lunacl_undepend_item() CVE-2025-38399 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: nfs: Clean up /proc/net/rpc/nfs when nfs_fs_proc_net_init() fails. syzbot reported a warning below [1] following a fault injection in nfs_fs_proc_net_init(). [0] When nfs_fs_proc_net_init() fails, /proc/net/rpc/nfs is not removed. Later, rpc_proc_exit() tries to remove /proc/net/rpc, and the warning is logged as the directory is not empty. Let's handle the error of nfs_fs_proc_net_init() properly. [0]: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:123) should_fail_ex (lib/fault-inject.c:73 lib/fault-inject.c:174) should_failslab (mm/failslab.c:46) kmem_cache_alloc_noprof (mm/slub.c:4178 mm/slub.c:4204) __proc_create (fs/proc/generic.c:427) proc_create_reg (fs/proc/generic.c:554) proc_create_net_data (fs/proc/proc_net.c:120) nfs_fs_proc_net_init (fs/nfs/client.c:1409) nfs_net_init (fs/nfs/inode.c:2600) ops_init (net/core/net_namespace.c:138) setup_net (net/core/net_namespace.c:443) copy_net_ns (net/core/net_namespace.c:576) create_new_namespaces (kernel/nsproxy.c:110) unshare_nsproxy_namespaces (kernel/nsproxy.c:218 (discriminator 4)) ksys_unshare (kernel/fork.c:3123) __x64_sys_unshare (kernel/fork.c:3190) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK> [1]: remove_proc_entry: removing non-empty directory 'net/rpc', leaking at least 'nfs' WARNING: CPU: 1 PID: 6120 at fs/proc/generic.c:727 remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727 Modules linked in: CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 RIP: 0010:remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727 Code: 3c 02 00 0f 85 85 00 00 00 48 8b 93 d8 00 00 00 4d 89 f0 4c 89 e9 48 c7 c6 40 ba a2 8b 48 c7 c7 60 b9 a2 8b e8 33 81 1d ff 90 <0f> 0b 90 90 e9 5f fe ff ff e8 04 69 5e ff 90 48 b8 00 00 00 00 00 RSP: 0018:ffffc90003637b08 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff88805f534140 RCX: ffffffff817a92c8 RDX: ffff88807da99e00 RSI: ffffffff817a92d5 RDI: 0000000000000001 RBP: ffff888033431ac0 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff888033431a00 R13: ffff888033431ae4 R14: ffff888033184724 R15: dffffc0000000000 FS: 0000555580328500(0000) GS:ffff888124a62000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f71733743e0 CR3: 000000007f618000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> sunrpc_exit_net+0x46/0x90 net/sunrpc/sunrpc_syms.c:76 ops_exit_list net/core/net_namespace.c:200 [inline] ops_undo_list+0x2eb/0xab0 net/core/net_namespace.c:253 setup_net+0x2e1/0x510 net/core/net_namespace.c:457 copy_net_ns+0x2a6/0x5f0 net/core/net_namespace.c:574 create_new_namespaces+0x3ea/0xa90 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:218 ksys_unshare+0x45b/0xa40 kernel/fork.c:3121 __do_sys_unshare kernel/fork.c:3192 [inline] __se_sys_unshare kernel/fork.c:3190 [inline] __x64_sys_unshare+0x31/0x40 kernel/fork.c:3190 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x490 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fa1a6b8e929 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 c ---truncated--- CVE-2025-38400 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: mtk-sd: Prevent memory corruption from DMA map failure If msdc_prepare_data() fails to map the DMA region, the request is not prepared for data receiving, but msdc_start_data() proceeds the DMA with previous setting. Since this will lead a memory corruption, we have to stop the request operation soon after the msdc_prepare_data() fails to prepare it. CVE-2025-38401 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: typec: displayport: Fix potential deadlock The deadlock can occur due to a recursive lock acquisition of `cros_typec_altmode_data::mutex`. The call chain is as follows: 1. cros_typec_altmode_work() acquires the mutex 2. typec_altmode_vdm() -> dp_altmode_vdm() -> 3. typec_altmode_exit() -> cros_typec_altmode_exit() 4. cros_typec_altmode_exit() attempts to acquire the mutex again To prevent this, defer the `typec_altmode_exit()` call by scheduling it rather than calling it directly from within the mutex-protected context. CVE-2025-38404 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: remove WARN on bad firmware input If the firmware gives bad input, that's nothing to do with the driver's stack at this point etc., so the WARN_ON() doesn't add any value. Additionally, this is one of the top syzbot reports now. Just print a message, and as an added bonus, print the sizes too. CVE-2025-38406 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix another leak in the submit error path put_unused_fd() doesn't free the installed file, if we've already done fd_install(). So we need to also free the sync_file. Patchwork: https://patchwork.freedesktop.org/patch/653583/ CVE-2025-38409 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 low In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix a fence leak in submit error path In error paths, we could unref the submit without calling drm_sched_entity_push_job(), so msm_job_free() will never get called. Since drm_sched_job_cleanup() will NULL out the s_fence, we can use that to detect this case. Patchwork: https://patchwork.freedesktop.org/patch/653584/ CVE-2025-38410 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks After retrieving WMI data blocks in sysfs callbacks, check for the validity of them before dereferencing their content. CVE-2025-38412 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850 GCC_GCC_PCIE_HOT_RST is wrongly defined for WCN7850, causing kernel crash on some specific platforms. Since this register is divergent for WCN7850 and QCN9274, move it to register table to allow different definitions. Then correct the register address for WCN7850 to fix this issue. Note IPQ5332 is not affected as it is not PCIe based device. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 CVE-2025-38414 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: NFC: nci: uart: Set tty->disc_data only in success path Setting tty->disc_data before opening the NCI device means we need to clean it up on error paths. This also opens some short window if device starts sending data, even before NCIUARTSETDRIVER IOCTL succeeded (broken hardware?). Close the window by exposing tty->disc_data only on the success path, when opening of the NCI device and try_module_get() succeeds. The code differs in error path in one aspect: tty->disc_data won't be ever assigned thus NULL-ified. This however should not be relevant difference, because of "tty->disc_data=NULL" in nci_uart_tty_open(). CVE-2025-38416 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: i2c: tegra: check msg length in SMBUS block read For SMBUS block read, do not continue to read if the message length passed from the device is '0' or greater than the maximum allowed bytes. CVE-2025-38425 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Add basic validation for RAS header If RAS header read from EEPROM is corrupted, it could result in trying to allocate huge memory for reading the records. Add some validation to header fields. CVE-2025-38426 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - check record size in ims_pcu_flash_firmware() The "len" variable comes from the firmware and we generally do trust firmware, but it's always better to double check. If the "len" is too large it could result in memory corruption when we do "memcpy(fragment->data, rec->data, len);" CVE-2025-38428 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: bus: mhi: ep: Update read pointer only after buffer is written Inside mhi_ep_ring_add_element, the read pointer (rd_offset) is updated before the buffer is written, potentially causing race conditions where the host sees an updated read pointer before the buffer is actually written. Updating rd_offset prematurely can lead to the host accessing an uninitialized or incomplete element, resulting in data corruption. Invoke the buffer write before updating rd_offset to ensure the element is fully written before signaling its availability. CVE-2025-38429 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/scheduler: signal scheduled fence when kill job When an entity from application B is killed, drm_sched_entity_kill() removes all jobs belonging to that entity through drm_sched_entity_kill_jobs_work(). If application A's job depends on a scheduled fence from application B's job, and that fence is not properly signaled during the killing process, application A's dependency cannot be cleared. This leads to application A hanging indefinitely while waiting for a dependency that will never be resolved. Fix this issue by ensuring that scheduled fences are properly signaled when an entity is killed, allowing dependent applications to continue execution. CVE-2025-38436 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: nbd: fix uaf in nbd_genl_connect() error path There is a use-after-free issue in nbd: block nbd6: Receive control failed (result -104) block nbd6: shutting down sockets ================================================================== BUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022 Write of size 4 at addr ffff8880295de478 by task kworker/u33:0/67 CPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0-rc5-syzkaller-00123-g2c89c1b655c0 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: nbd6-recv recv_work 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 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_dec include/linux/atomic/atomic-instrumented.h:592 [inline] recv_work+0x694/0xa80 drivers/block/nbd.c:1022 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> nbd_genl_connect() does not properly stop the device on certain error paths after nbd_start_device() has been called. This causes the error path to put nbd->config while recv_work continue to use the config after putting it, leading to use-after-free in recv_work. This patch moves nbd_start_device() after the backend file creation. CVE-2025-38443 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_serial: Fix race condition in TTY wakeup A race condition occurs when gs_start_io() calls either gs_start_rx() or gs_start_tx(), as those functions briefly drop the port_lock for usb_ep_queue(). This allows gs_close() and gserial_disconnect() to clear port.tty and port_usb, respectively. Use the null-safe TTY Port helper function to wake up TTY. Example CPU1: CPU2: gserial_connect() // lock gs_close() // await lock gs_start_rx() // unlock usb_ep_queue() gs_close() // lock, reset port.tty and unlock gs_start_rx() // lock tty_wakeup() // NPE CVE-2025-38448 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight Reject migration of SEV{-ES} state if either the source or destination VM is actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the section between incrementing created_vcpus and online_vcpus. The bulk of vCPU creation runs _outside_ of kvm->lock to allow creating multiple vCPUs in parallel, and so sev_info.es_active can get toggled from false=>true in the destination VM after (or during) svm_vcpu_create(), resulting in an SEV{-ES} VM effectively having a non-SEV{-ES} vCPU. The issue manifests most visibly as a crash when trying to free a vCPU's NULL VMSA page in an SEV-ES VM, but any number of things can go wrong. BUG: unable to handle page fault for address: ffffebde00000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline] RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline] RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline] RIP: 0010:PageHead include/linux/page-flags.h:866 [inline] RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067 Code: <49> f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0 RSP: 0018:ffff8984551978d0 EFLAGS: 00010246 RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000 RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000 R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000 R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000 FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0 DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: <TASK> sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169 svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515 kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396 kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline] kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490 kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895 kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310 kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369 __fput+0x3e4/0x9e0 fs/file_table.c:465 task_work_run+0x1a9/0x220 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x7f0/0x25b0 kernel/exit.c:953 do_group_exit+0x203/0x2d0 kernel/exit.c:1102 get_signal+0x1357/0x1480 kernel/signal.c:3034 arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218 do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f87a898e969 </TASK> Modules linked in: gq(O) gsmi: Log Shutdown Reason 0x03 CR2: ffffebde00000000 ---[ end trace 0000000000000000 ]--- Deliberately don't check for a NULL VMSA when freeing the vCPU, as crashing the host is likely desirable due to the VMSA being consumed by hardware. E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a bogus VMSA page. Accessing P ---truncated--- CVE-2025-38455 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: vsock: Fix transport_* TOCTOU Transport assignment may race with module unload. Protect new_transport from becoming a stale pointer. This also takes care of an insecure call in vsock_use_local_transport(); add a lockdep assert. BUG: unable to handle page fault for address: fffffbfff8056000 Oops: Oops: 0000 [#1] SMP KASAN RIP: 0010:vsock_assign_transport+0x366/0x600 Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CVE-2025-38461 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: vsock: Fix transport_{g2h,h2g} TOCTOU vsock_find_cid() and vsock_dev_do_ioctl() may race with module unload. transport_{g2h,h2g} may become NULL after the NULL check. Introduce vsock_transport_local_cid() to protect from a potential null-ptr-deref. KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] RIP: 0010:vsock_find_cid+0x47/0x90 Call Trace: __vsock_bind+0x4b2/0x720 vsock_bind+0x90/0xe0 __sys_bind+0x14d/0x1e0 __x64_sys_bind+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0 Call Trace: __x64_sys_ioctl+0x12d/0x190 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CVE-2025-38462 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: tcp: Correct signedness in skb remaining space calculation Syzkaller reported a bug [1] where sk->sk_forward_alloc can overflow. When we send data, if an skb exists at the tail of the write queue, the kernel will attempt to append the new data to that skb. However, the code that checks for available space in the skb is flawed: ''' copy = size_goal - skb->len ''' The types of the variables involved are: ''' copy: ssize_t (s64 on 64-bit systems) size_goal: int skb->len: unsigned int ''' Due to C's type promotion rules, the signed size_goal is converted to an unsigned int to match skb->len before the subtraction. The result is an unsigned int. When this unsigned int result is then assigned to the s64 copy variable, it is zero-extended, preserving its non-negative value. Consequently, copy is always >= 0. Assume we are sending 2GB of data and size_goal has been adjusted to a value smaller than skb->len. The subtraction will result in copy holding a very large positive integer. In the subsequent logic, this large value is used to update sk->sk_forward_alloc, which can easily cause it to overflow. The syzkaller reproducer uses TCP_REPAIR to reliably create this condition. However, this can also occur in real-world scenarios. The tcp_bound_to_half_wnd() function can also reduce size_goal to a small value. This would cause the subsequent tcp_wmem_schedule() to set sk->sk_forward_alloc to a value close to INT_MAX. Further memory allocation requests would then cause sk_forward_alloc to wrap around and become negative. [1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47 CVE-2025-38463 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: drm/exynos: exynos7_drm_decon: add vblank check in IRQ handling If there's support for another console device (such as a TTY serial), the kernel occasionally panics during boot. The panic message and a relevant snippet of the call stack is as follows: Unable to handle kernel NULL pointer dereference at virtual address 000000000000000 Call trace: drm_crtc_handle_vblank+0x10/0x30 (P) decon_irq_handler+0x88/0xb4 [...] Otherwise, the panics don't happen. This indicates that it's some sort of race condition. Add a check to validate if the drm device can handle vblanks before calling drm_crtc_handle_vblank() to avoid this. CVE-2025-38467 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: tls: always refresh the queue when reading sock After recent changes in net-next TCP compacts skbs much more aggressively. This unearthed a bug in TLS where we may try to operate on an old skb when checking if all skbs in the queue have matching decrypt state and geometry. BUG: KASAN: slab-use-after-free in tls_strp_check_rcv+0x898/0x9a0 [tls] (net/tls/tls_strp.c:436 net/tls/tls_strp.c:530 net/tls/tls_strp.c:544) Read of size 4 at addr ffff888013085750 by task tls/13529 CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme Call Trace: kasan_report+0xca/0x100 tls_strp_check_rcv+0x898/0x9a0 [tls] tls_rx_rec_wait+0x2c9/0x8d0 [tls] tls_sw_recvmsg+0x40f/0x1aa0 [tls] inet_recvmsg+0x1c3/0x1f0 Always reload the queue, fast path is to have the record in the queue when we wake, anyway (IOW the path going down "if !strp->stm.full_len"). CVE-2025-38471 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important 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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: rpl: Fix use-after-free in rpl_do_srh_inline(). Running lwt_dst_cache_ref_loop.sh in selftest with KASAN triggers the splat below [0]. rpl_do_srh_inline() fetches ipv6_hdr(skb) and accesses it after skb_cow_head(), which is illegal as the header could be freed then. Let's fix it by making oldhdr to a local struct instead of a pointer. [0]: [root@fedora net]# ./lwt_dst_cache_ref_loop.sh ... TEST: rpl (input) [ 57.631529] ================================================================== BUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174) Read of size 40 at addr ffff888122bf96d8 by task ping6/1543 CPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:409 mm/kasan/report.c:521) kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636) kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1)) __asan_memmove (mm/kasan/shadow.c:94 (discriminator 2)) rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174) rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282) lwtunnel_input (net/core/lwtunnel.c:459) ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1)) __netif_receive_skb_one_core (net/core/dev.c:5967) process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440) __napi_poll.constprop.0 (net/core/dev.c:7452) net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643) handle_softirqs (kernel/softirq.c:579) do_softirq (kernel/softirq.c:480 (discriminator 20)) </IRQ> <TASK> __local_bh_enable_ip (kernel/softirq.c:407) __dev_queue_xmit (net/core/dev.c:4740) ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141) ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226) ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248) ip6_send_skb (net/ipv6/ip6_output.c:1983) rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918) __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1)) __x64_sys_sendto (net/socket.c:2231) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f68cffb2a06 Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08 RSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06 RDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003 RBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c R10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4 R13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0 </TASK> Allocated by task 1543: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1)) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249) kmalloc_reserve (net/core/skbuff.c:581 (discriminator 88)) __alloc_skb (net/core/skbuff.c:669) __ip6_append_data (net/ipv6/ip6_output.c:1672 (discriminator 1)) ip6_ ---truncated--- CVE-2025-38476 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important 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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: comedi: Fix initialization of data for instructions that write to subdevice Some Comedi subdevice instruction handlers are known to access instruction data elements beyond the first `insn->n` elements in some cases. The `do_insn_ioctl()` and `do_insnlist_ioctl()` functions allocate at least `MIN_SAMPLES` (16) data elements to deal with this, but they do not initialize all of that. For Comedi instruction codes that write to the subdevice, the first `insn->n` data elements are copied from user-space, but the remaining elements are left uninitialized. That could be a problem if the subdevice instruction handler reads the uninitialized data. Ensure that the first `MIN_SAMPLES` elements are initialized before calling these instruction handlers, filling the uncopied elements with 0. For `do_insnlist_ioctl()`, the same data buffer elements are used for handling a list of instructions, so ensure the first `MIN_SAMPLES` elements are initialized for each instruction that writes to the subdevice. CVE-2025-38478 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: comedi: Fix use of uninitialized data in insn_rw_emulate_bits() For Comedi `INSN_READ` and `INSN_WRITE` instructions on "digital" subdevices (subdevice types `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO`, and `COMEDI_SUBD_DIO`), it is common for the subdevice driver not to have `insn_read` and `insn_write` handler functions, but to have an `insn_bits` handler function for handling Comedi `INSN_BITS` instructions. In that case, the subdevice's `insn_read` and/or `insn_write` function handler pointers are set to point to the `insn_rw_emulate_bits()` function by `__comedi_device_postconfig()`. For `INSN_WRITE`, `insn_rw_emulate_bits()` currently assumes that the supplied `data[0]` value is a valid copy from user memory. It will at least exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in "comedi_fops.c" ensure at lease `MIN_SAMPLES` (16) elements are allocated. However, if `insn->n` is 0 (which is allowable for `INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may contain uninitialized data, and certainly contains invalid data, possibly from a different instruction in the array of instructions handled by `do_insnlist_ioctl()`. This will result in an incorrect value being written to the digital output channel (or to the digital input/output channel if configured as an output), and may be reflected in the internal saved state of the channel. Fix it by returning 0 early if `insn->n` is 0, before reaching the code that accesses `data[0]`. Previously, the function always returned 1 on success, but it is supposed to be the number of data samples actually read or written up to `insn->n`, which is 0 in this case. CVE-2025-38480 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too large The handling of the `COMEDI_INSNLIST` ioctl allocates a kernel buffer to hold the array of `struct comedi_insn`, getting the length from the `n_insns` member of the `struct comedi_insnlist` supplied by the user. The allocation will fail with a WARNING and a stack dump if it is too large. Avoid that by failing with an `-EINVAL` error if the supplied `n_insns` value is unreasonable. Define the limit on the `n_insns` value in the `MAX_INSNS` macro. Set this to the same value as `MAX_SAMPLES` (65536), which is the maximum allowed sum of the values of the member `n` in the array of `struct comedi_insn`, and sensible comedi instructions will have an `n` of at least 1. CVE-2025-38481 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 low In the Linux kernel, the following vulnerability has been resolved: comedi: das6402: Fix bit shift out of bounds When checking for a supported IRQ number, the following test is used: /* IRQs 2,3,5,6,7, 10,11,15 are valid for "enhanced" mode */ if ((1 << it->options[1]) & 0x8cec) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test. Valid `it->options[1]` values that select the IRQ will be in the range [1,15]. The value 0 explicitly disables the use of interrupts. CVE-2025-38482 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: comedi: das16m1: Fix bit shift out of bounds When checking for a supported IRQ number, the following test is used: /* only irqs 2, 3, 4, 5, 6, 7, 10, 11, 12, 14, and 15 are valid */ if ((1 << it->options[1]) & 0xdcfc) { However, `it->options[i]` is an unchecked `int` value from userspace, so the shift amount could be negative or out of bounds. Fix the test by requiring `it->options[1]` to be within bounds before proceeding with the original test. CVE-2025-38483 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: iio: accel: fxls8962af: Fix use after free in fxls8962af_fifo_flush fxls8962af_fifo_flush() uses indio_dev->active_scan_mask (with iio_for_each_active_channel()) without making sure the indio_dev stays in buffer mode. There is a race if indio_dev exits buffer mode in the middle of the interrupt that flushes the fifo. Fix this by calling synchronize_irq() to ensure that no interrupt is currently running when disabling buffer mode. Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read [...] _find_first_bit_le from fxls8962af_fifo_flush+0x17c/0x290 fxls8962af_fifo_flush from fxls8962af_interrupt+0x80/0x178 fxls8962af_interrupt from irq_thread_fn+0x1c/0x7c irq_thread_fn from irq_thread+0x110/0x1f4 irq_thread from kthread+0xe0/0xfc kthread from ret_from_fork+0x14/0x2c CVE-2025-38485 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: soc: aspeed: lpc-snoop: Don't disable channels that aren't enabled Mitigate e.g. the following: # echo 1e789080.lpc-snoop > /sys/bus/platform/drivers/aspeed-lpc-snoop/unbind ... [ 120.363594] Unable to handle kernel NULL pointer dereference at virtual address 00000004 when write [ 120.373866] [00000004] *pgd=00000000 [ 120.377910] Internal error: Oops: 805 [#1] SMP ARM [ 120.383306] CPU: 1 UID: 0 PID: 315 Comm: sh Not tainted 6.15.0-rc1-00009-g926217bc7d7d-dirty #20 NONE ... [ 120.679543] Call trace: [ 120.679559] misc_deregister from aspeed_lpc_snoop_remove+0x84/0xac [ 120.692462] aspeed_lpc_snoop_remove from platform_remove+0x28/0x38 [ 120.700996] platform_remove from device_release_driver_internal+0x188/0x200 ... CVE-2025-38487 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again Commit 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") has accidentally removed the critical piece of commit c730fce7c70c ("s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL"), causing intermittent kernel panics in e.g. perf's on_switch() prog to reappear. Restore the fix and add a comment. CVE-2025-38489 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate 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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important In the Linux kernel, the following vulnerability has been resolved: dm-bufio: fix sched in atomic context If "try_verify_in_tasklet" is set for dm-verity, DM_BUFIO_CLIENT_NO_SLEEP is enabled for dm-bufio. However, when bufio tries to evict buffers, there is a chance to trigger scheduling in spin_lock_bh, the following warning is hit: BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2745 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 123, name: kworker/2:2 preempt_count: 201, expected: 0 RCU nest depth: 0, expected: 0 4 locks held by kworker/2:2/123: #0: ffff88800a2d1548 ((wq_completion)dm_bufio_cache){....}-{0:0}, at: process_one_work+0xe46/0x1970 #1: ffffc90000d97d20 ((work_completion)(&dm_bufio_replacement_work)){....}-{0:0}, at: process_one_work+0x763/0x1970 #2: ffffffff8555b528 (dm_bufio_clients_lock){....}-{3:3}, at: do_global_cleanup+0x1ce/0x710 #3: ffff88801d5820b8 (&c->spinlock){....}-{2:2}, at: do_global_cleanup+0x2a5/0x710 Preemption disabled at: [<0000000000000000>] 0x0 CPU: 2 UID: 0 PID: 123 Comm: kworker/2:2 Not tainted 6.16.0-rc3-g90548c634bd0 #305 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: dm_bufio_cache do_global_cleanup Call Trace: <TASK> dump_stack_lvl+0x53/0x70 __might_resched+0x360/0x4e0 do_global_cleanup+0x2f5/0x710 process_one_work+0x7db/0x1970 worker_thread+0x518/0xea0 kthread+0x359/0x690 ret_from_fork+0xf3/0x1b0 ret_from_fork_asm+0x1a/0x30 </TASK> That can be reproduced by: veritysetup format --data-block-size=4096 --hash-block-size=4096 /dev/vda /dev/vdb SIZE=$(blockdev --getsz /dev/vda) dmsetup create myverity -r --table "0 $SIZE verity 1 /dev/vda /dev/vdb 4096 4096 <data_blocks> 1 sha256 <root_hash> <salt> 1 try_verify_in_tasklet" mount /dev/dm-0 /mnt -o ro echo 102400 > /sys/module/dm_bufio/parameters/max_cache_size_bytes [read files in /mnt] CVE-2025-38496 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: Fix OOB read on empty string write When writing an empty string to either 'qw_sign' or 'landingPage' sysfs attributes, the store functions attempt to access page[l - 1] before validating that the length 'l' is greater than zero. This patch fixes the vulnerability by adding a check at the beginning of os_desc_qw_sign_store() and webusb_landingPage_store() to handle the zero-length input case gracefully by returning immediately. CVE-2025-38497 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 moderate 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-15-sp6-chost-byos-v20250918-x86-64:kernel-default-6.4.0-150600.23.65.1 important libcurl accidentally skips the certificate verification for QUIC connections when connecting to a host specified as an IP address in the URL. Therefore, it does not detect impostors or man-in-the-middle attacks. CVE-2025-4947 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:curl-8.14.1-150600.4.28.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:libcurl4-8.14.1-150600.4.28.1 moderate libcurl supports *pinning* of the server certificate public key for HTTPS transfers. Due to an omission, this check is not performed when connecting with QUIC for HTTP/3, when the TLS backend is wolfSSL. Documentation says the option works with wolfSSL, failing to specify that it does not for QUIC and HTTP/3. Since pinning makes the transfer succeed if the pin is fine, users could unwittingly connect to an impostor server without noticing. CVE-2025-5025 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:curl-8.14.1-150600.4.28.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:libcurl4-8.14.1-150600.4.28.1 moderate Due to a mistake in libcurl's WebSocket code, a malicious server can send a particularly crafted packet which makes libcurl get trapped in an endless busy-loop. There is no other way for the application to escape or exit this loop other than killing the thread/process. This might be used to DoS libcurl-using application. CVE-2025-5399 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:curl-8.14.1-150600.4.28.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:libcurl4-8.14.1-150600.4.28.1 moderate The regcomp function in the GNU C library version from 2.4 to 2.41 is subject to a double free if some previous allocation fails. It can be accomplished either by a malloc failure or by using an interposed malloc that injects random malloc failures. The double free can allow buffer manipulation depending of how the regex is constructed. This issue affects all architectures and ABIs supported by the GNU C library. CVE-2025-8058 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:glibc-2.38-150600.14.37.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:glibc-locale-2.38-150600.14.37.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:glibc-locale-base-2.38-150600.14.37.1 moderate 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-15-sp6-chost-byos-v20250918-x86-64:curl-8.14.1-150600.4.28.1 Public Cloud Image google/sles-15-sp6-chost-byos-v20250918-x86-64:libcurl4-8.14.1-150600.4.28.1 important